Personally, I wrote 200K lines of my B2B SaaS before agentic coding came around. With Sonnet 4 in Agent mode, I'd say I now write maybe 20% of the ongoing code from day to day, perhaps less. Interactive Sonnet in VS Code and GitHub Copilot Agents (autonomous agents running on GitHub's servers) do the other 80%. The more I document in Markdown, the higher that percentage becomes. I then carefully review and test.

I use aider and your description doesn't match my experience, even with a relatively bad-at-coding model (gpt-5). It does actually work and it does generate "good" code - it even matches the style of the existing code.

Prompting is very important, and in an existing code base the success rate is immensely higher if you can hint at a specific implementation - i.e. something a senior who is familiar with the codebase somewhat can do, but a junior may struggle with.

It's important to be clear eyed about where we are here. I think overall I am still faster doing things manually than iterating with aider on an existing code base, but the margin is not very much, and it's only going to get better.

Even though it can do some work a junior could do, it can't ever replace a junior human... because a junior human also goes to meetings, drives discussions, and eventually becomes a senior! But management may not care about that fact.

But I have not yet been able to consistently get value out of vibe coding. It's great for one-off tasks. I use it to create matplotlib charts just by telling it what I want and showing it the schema of the data I have. It nails that about 90% of the time. I have it spit out close-ended shell scripts, like recently I had it write me a small CLI tool to organize my Raw photos into a directory structure I want by reading the EXIF data and sorting the images accordingly. It's great for this stuff.

But anything bigger it seems to do useless crap. Creates data models that already exist in the project. Makes unrelated changes. Hallucinates API functions that don't exist. It's just not worth it to me to have to check its work. By the time I've done that, I could have written it myself, and writing the code is usually the most pleasurable part of the job to me.

I think the way I'm finding LLMs to be useful is that they are a brilliant interface to query with, but I have not yet seen any use cases I like where the output is saved, directly incorporated into work, or presented to another human that did not do the prompting.

If you spend a lot of time thinking about what you want, describing the inner workings, edge cases, architecture and library choices, and put that into a thoughtful markdown, then maybe after a couple of iterations you will get half decent code. It certainly makes a difference between that and a short "implement X" prompt.

But it makes one think - at that point (writing a good prompt that is basically a spec), you've basically solved the problem already. So LLM in this case is little more than a glorified electric typewriter. It types faster than you, but you did most of the thinking.

Granted, I may be a inexpert prompter, but at the same time, I'm asking for basic things, as a test, and it just fails miserably most of the time.

Just yesterday I uploaded a few files of my code (each about 3000+ lines) into a gpt5 project and asked in assistance in changing a lot of database calls into a caching system, and it proceeded to create a full 500 line file with all the caching objects and functions I needed. Then we went section through section of the main 3000+ line file to change parts of the database queries into the cached version. [I didn't even really need to do this, it basically detected everything I would need changing at once and gave me most of it, but I wanted to do it in smaller chunks so I was sure what was going on]

Could I have done this without AI? Sure.. but this was basically like having a second pair of eyes and validating what I'm doing. And saving me a bunch of time so I'm not writing everything from scratch. I have the base template of what I need then I can improve it from there.

All the code it wrote was perfectly clean.. and this is not a one off, I've been using it daily for the last year for everything. It almost completely replaces my need to have a junior developer helping me.

There are lots of personal projects that I have wanted to build for years but have pushed off because the “getting started cost” is too high, I get frustrated and annoyed and don’t get far before giving up. Being able to get the tedious crap out of the way lowers the barrier to entry and I can actually do the real project, and get it past some finish line.

Am I learning as much as I would had I powered through it without AI assistance? Probably not, but I am definitely learning more than I would if I had simply not finished (or even started) the project at all.

> (…)

> I’m not even sure AI is good for any engineer

In that case I’m not sure you really agree with this CEO, who is all-in on the idea of LLMs for coding, going so far as to proudly say 80% of engineers at AWS use it and that that number will only rise. Listen to the interview, you don’t even need ten minutes.

Memorization is not a panacea. I never found memorizing l33t code problems to be edifying. I think it's because those kinds of tight, self-referential, clever programs are far removed from the activity of writing applications. Most working programmers do not run into a novel algorithm problem but once or twice a career. Application programming has more the flavor of a human-mediated graph-traversal, where the human has access to a node's local state and they improvise movement and mutation using only that local state plus some rapidly decaying stack. That is, there is no well-defined sequence for any given real-world problem, only heuristics.

A regular old competent developer can quickly pick up whatever stack is used. After all, they have to; Every company is their own bespoke mess of technologies. The idea that you can just slap "15 years of React experience" on a job ad and that the unicorn you get will be day-1 maximally productive is ludicrous. There is always an onboarding time.

But employers in this field don't "get" that. For regular companies they're infested by managers imported from non-engineering fields, who treat software like it's the assembly line for baking tins or toilet paper. Startups, who already have fewer resources to train people with, are obsessed with velocity and shitting out an MVP ASAP so they can go collect the next funding round. Big Tech is better about this, but has it's own problems going on and it seems that the days of Big Tech being the big training houses is also over.

It's not even a purely collective problem. Recruitment is so expensive, but all the money spent chasing unicorns & the opportunity costs of being understaffed just get handwaved. Rather spend $500,000 on the hunt than $50,000 on training someone into the role.

And speaking of collective problems. This is a good example of how this field suffers from having no professional associations that can stop employers from sinking the field with their tragedies of the commons. (Who knows, maybe unions will get more traction now that people are being laid off & replaced with outsourced workers for no legitimate business reason.)

- something we've been doing since forever

- the latest trend that can be picked up just-in-time if you'll ever need it

Now as a hiring manager I’ll say I regularly find that those who’ve had humanities experience are way more capable and the hard parts of analysis and understanding. Of course I’m biased as a dual cs/philosophy major but it’s very rare I’m looking for someone who can just write a lot of code. Especially juniors as analytical thinking is way harder to teach than how to program.

I miss her jokes against anxious nerds that just wanted to code :(

Don't forget the rise of boot camps where some educators are not always aligned with some sort of higher ethical standards.

Coding, doctors, plumber… different information, often similar skill sets.

I worked a job doing tech support for some enterprise level networking equipment. It was the late 1990s and we were desperate for warm bodies. Hired a former truck driver who just so happened to do a lot of woodworking and other things.

Great hire.

However most of us are not in that situation. It is better for us to just look up those details as we need them because it gives us more room to handle a broader variety of situations.

I meam, yes, to an extent you can teach how to think: critical thinking and logic are topics you can teach and people who take their teaching to heart can become better thinkers. However, those topics cannot impart creativity. Critical thinking is called exactly that because it's about tools and skills for separating bad thinking from good thinking. The skill of generating good thinking probably cannot be taught; it can only be improved with problem-solving practice.

Unlike my teachers, none of my bosses ever put me in an empty room with only a pencil and a sheet of paper to solve given problems.

In general, I also attend your church.

However, as I preached in that church, I had two students over the years.

* One was from an African country and told me that where he grew up, you could not "just look up data that might be relevant" because internet access was rare.

* The other was an ex US Navy officer who was stationed on a nuclear sub. She and the rest of the crew had to practice situations where they were in an emergency and cut off from the rest of the world.

Memorization of considerable amounts of data was important to both of them.

Very anecdotally, but I hazard that most of these types of low-hanging fruit, low-value add roles are much less common since they tended to be blockers for operational improvement. Six-sigma, Lean, various flavors of Agile would often surface these low performers up and they either improved or got shown the door between 2005 - 2020.

Not that everyone is 100% all the time, every day, but what we are left with is often people that are highly competent at not just their task list but at their job.

It’s also hard to teach people “how to think” while at the same time teaching them practical skills - there’s only so many hours in a day, and most education is setup as a way to get as many people as possible into shape for taking on jobs where “thinking” isn’t really a positive trait, as it’d lead to constant restructuring and questioning of the status quo

I've had a frustrating experience the past few years trying to hire junior sysadmins because of a real lack of problem solving skills once something went wrong outside of various playbooks they memorized to follow.

I don't need someone who can follow a pre-written playbook, I have ansible for that. I need someone that understands theory, regardless of specific implementations, and can problem solve effectively so they can handle unpredictable or novel issues.

To put another way, I can teach a junior the specifics of bind9 named.conf, or the specifics of our own infrastructure, but I shouldn't be expected to teach them what DNS in general is and how it works.

But the candidates we get are the opposite - they know specific tools, but lack more generalized theory and problem solving skills.

My experience as a professor and a student is that this doesn't make any difference. Unless you can copy verbatim the solution to your problem from the book (which never happens), you better have a good understanding of the subject in order to solve problems in the allocated time. You're not going to acquire that knowledge during your test.

I think the problem with this is that it requires the professor to mentally fully engage when marking assignments and many educators do not have the capacity and/or desire to do so.

For anyone looking for resources, may we recommend:

* The Art of Doing Science and Engineering by Richard Hamming (lectures are available on YouTube as well)

* Measurement by Paul Lockhart (for teaching mindset)

Ahh, but this is part of the problem. Yes, they have access, but there is -so much- information, it punches through our context window. So we resort to executive summaries, or convince ourselves that something that's relevant is actually not.

At least an LLM can take full view of the context in aggregate and peel out signal. There is value there, but no jobs are being replaced

The bigger your mental toolbox the more effective you will be at solving the problems. Looking up a tool and learning just enough to use it JIT is much slower than using a handy tool that you already masterfully know how to use.

This is as true for physical tools as for programming concepts like algorithms and data structures. In the worst case you won’t even know to look for a tool and will use whatever is handy, like the proverbial hammer.

(I do mean memorisation fairly broadly, it doesn't have to mean reciting a meaningless list of items.)

Most of us are also old enough to have had a chance to develop taste in code and writing. Many of the young generation lack the experience to distinguish good writing from LLM drivel.

in developing areas, they actually implement more modern models commonly, as its newer and free to implement newer things.

those newer models focus more on exactly this. teach a person how to go through the process of finding solutions. rather than 'knowing a lot to enable the process of thinking'.

not saying what is better or worse, but reading this comment and article it reminds me of this.

a lot of people i see, they know tons of interesting things, but anything outside of their knowledge is a complete mystery.

all the while ppl from developing areas learn to solve issues. alot of individuals from there also, get out of their poverty and do really well for themselves.

ofcourse, this is a generalization and doesnt hold up in all cases. but i cant help think about it.

a lot of my colleagues dont know how to solve problems simply because they dont RTFM. they rely on knowledge from their education which is already outdated before they even sign up.. i try to teach them to RTFM. it seems hopeless. they look at me , downwards, because i have no papers. but if shit hits the fan, they come to me. solve the prolbem.

a wise guy i met once said (likely not his words). there are 2 type of ppl. those who think in problems, and those who think in solutions.

id related that to education, not prebaked human properties.

Finding the correct balance for a given class it hard. Generally, the lower level the education, the more it should be closed books because the more it is about being able to manually solve the smaller challenges that are already well solved so you build up the skills needed to even tackle the larger challenges. The higher the education level, the more it is about being able to apply those skills to then tackle a problem, and one of those skills is being able to pull relevant formulas and such from the larger body of known formulas.

Forcing kids to sit and memorize facts isn’t suddenly going to make them a better thinker, but much of my process of being a better thinker is something akin to sitting around and memorizing facts. (With a healthy dose of interacting substantively and curiously with said facts)

VP->Public: "We'll replace all our engineers with AI in two years"

Boss->VP: "I mean we need to fire VPs because AI"

VP->Public: "Replacing people with AI is stupid"

"It just means that each of us has to get more in tune with what our customers need and what the actual end thing is that we're going to try to go build, because that's going to be more and more of what the work is as opposed to sitting down and actually writing code...."

https://www.businessinsider.com/aws-ceo-developers-stop-codi...

If you read the full remarks they're consistent with what he says here. He says "writing code" may be a skill that's less useful, which is why it's important to hire junior devs and teach them how to learn so they learn the skills that are useful.

Some subset of the population likes to pretend their workforce is a cost that provides less than zero value or utility, and all the value and utility comes from shareholders.

But if this isn't true, and collective skill is worth value, then saying anyone can have that with AI at least has some headwind on your share price - which is all they care about.

Does that offset a potential tailwind from slightly higher margins?

I don't think any established company should be cheerleading that anyone can easily upset their monopoly with a couple of carefully crafted prompts.

It was always kind of strange to me, and seemed as though they were telling everyone, our moat is gone, and that is good.

If you really believed anyone could do anything with AI, then the risk of PEs collapsing would be high, which would be bad for the capital class. Now you have to correctly guess what's the next best thing constantly to keep your ROI instead of just parking it in save havens - like FAANG.

It can only mean one thing: the music is about to stop.

“My view is you absolutely want to keep hiring kids out of college and teaching them the right ways to go build software and decompose problems and think about it, just as much as you ever have.” - Matt Garman

"We will need fewer people doing some of the jobs that are being done today” - Amazon CEO Andy Jassy

Maybe they differ in degree but not in sentiment.

If you're quoting something, the only ethical thing to do is as verbatim as possible and with a sufficient amount of context. Speeches should not be cleaned up to what you think they should have said.

Now, the question of who you go to for quotes, on the other hand .. that's how issues are really pushed around the frame.

From the perspective of a former employee. I knew that going in though. I was 46 at the time, AWS was my 8th job and knowing AWS’s reputation from 2nd and 3rd hand information, I didn’t even entertain an opportunity that would have forced me to relocate.

I interviewed for a “field by design” role that was “permanently remote” [sic].

But even those positions had an RTO mandate after I already left.

In my experience if you do this and break the problem down into small pieces, the AI can implement the pieces for you.

It can save a lot of time typing and googling for docs.

That said, once the result exceeds a certain level of complexity, you can't really ask it to implement changes to existing code anymore, since it stops understanding it.

At which point you now have to do it yourself, but you know the codebase less well than if you'd hand written it.

So, my upshot is so far that it works great for small projects and for prototyping, but the gain after a certain level of complexity is probably quite small.

But then, I've also find quite some value in using it as a code search engine and to answer questions about the code, so maybe if nothing else that would be where the benefit comes from.

> "Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs." -- Bill Gates

Do we reward the employee who has added the most weight? Do we celebrate when the AI has added a lot of weight?

At first, it seems like, no, we shouldn't, but actually, it depends. If a person or AI is adding a lot of weight, but it is really important weight, like the engines or the main structure of the plane, then yeah, even though it adds a lot of weight, it's still doing genuinely impressive work. A heavy airplane is more impressive than a light weight one (usually).

I don't know how true this is in fact, but I do know how true this is in my work - you cannot apply some arbitrary "make the number bigger" goal to everything and expect it to improve anything. It feels a bit weird seeing "write more lines of code" becoming a key metric again. It never worked, and is damn-near provably never going to work. The value of source code is not in any way tied to its quantity, but value still proves hard to quantify, 40 years later.

0. https://www.folklore.org/Negative_2000_Lines_Of_Code.html

I ask an AI 4 times to write a method for me. After it keeps failing, I just write it myself. AI wrote 80% of the code!

I just won't use that information in quite the excitable, optimistic way they offer it.

I bet Google has a lot of tools to say convert a library from one language to another or generate a library based on an API spec. The 30% of code these LLMs are supposedly writing is probably in this camp, not net novel new features.

Especially with the amount of money that was put into just astroturfing the technology as more than it is.

From a person who is responsible for delivering projects, I’ve never thought “it sure would be nice if I had a few junior devs”. Why when I can poach an underpaid mid level developer for 20% more?

The hype train is going to keep on moving for a while yet though.

I think sometimes the definition of work gets narrowed to a point so infinitesimal that everyone but the speaker is just a lazy nobody.

There was an excellent article on here about working at enterprise scale. My experience has been similar. You get to do work that feels really real, almost like school assignments with instant feedback and obvious rewards when you're at a small company. When I worked at big companies it all felt like bullshit until I screwed it up and a senator was interested in "Learning more" (for example).

The last few 9s are awful hard to chase down and a lot of the steps of handling edge case failures or features are extremely manual.

1.) Elon fired 80% of twitter and 3 years later it still hasn't collapsed or fallen into technical calamity. Every tech board/CEO took note of that.

2.) Every kid and their sister going to college who wants a middle class life with generous working conditions is targeting tech. Every teenage nerd saw those over employed guys making $600k from their couch during the pandemic.

You're committing the classic fallacy around microservices here. The services themselves are simpler. The whole software is not.

When you take a classic monolith and split it up into microservices that are individually simple, the complexity does not go away, it simply moves into the higher abstractions. The complexity now lives in how the microservices interact.

In reality, the barrier to entry on monoliths wasn't that high either. You could get "low productivity employees" (I'd recommend you just call them "novices" or "juniors") to do the work, it'd just be best served with tomato sauce rather than deployed to production.

The same applies to microservices. You can have inexperienced devs build out individual microservices, but to stitch them together well is hard, arguably harder than ye-olde-monolith now that Java and more recent languages have good module systems.

I think it depends on the industry. In safety critical systems, you need to be testing, making documentation, architectural artifacts, meeting with customers, etc

There's not that much idle time. Unless you mean idle time actually writing code and that's not always a full time job.

Big businesses don’t inherently require the complexity of architecture they have. There is always a path-dependent evolution and vestigial complexity proportional to how large and fast they grew.

The real purpose of large scale architecture is to scale teams much moreso than business logic. But why does headcount grow? Is it because domains require it? Sure that’s what ambitious middle managers will say, but the real reason is you have money to invest in growth (whether from revenue or from a VC). For any complex architecture there is usually a dramatically simpler one that could still move the essential bits around, it just might not support the same number of engineers delineated into different teams with narrower responsibilities.

The general headcount growth and architecture trajectory is therefore governed by business success. When we’re growing we hire and we create complex architecture to chase growth in as many directions as possible. Eventually when growth slows we have a system that is so complex it requires a lot of people just to understand and maintain—even if the headcount is longer justified those with power in the human structure will bend over backwards to justify themselves. This is where the playbook changes and a private equity (or Elon) mentality is applied to just ruthlessly cut and force the rest of the people how to keep the lights on.

I consider advances in AI and productivity orthogonal to all this. It will affect how people do their jobs, what is possible, and the economics of that activity, but the fundamental dynamics of scale and architectural complexity will remain. They’ll still hire more people to grow and look for ways to apply them.

https://nordicapis.com/the-bezos-api-mandate-amazons-manifes...

The question is why. You mention microservices. I'm not convinced.

Many think it is "horizontals". Possible, these taxes add up it is true.

Perhaps it is cultural? Perhaps it has to do with the workforce in some manner. I don't know and AFAIK it has not been rigorously studied.

I’m really tired of this trope. I’ve spent my whole career on “boring CRUD” and the number of relational db backed apps I’ve seen written by devs who’ve never heard of isolation levels is concerning (including myself for a time).

Coincidentally, as soon as these apps see any scale issues pop up.

At least in my personal case, struggling with renewal at Virgin Broadband, multiple humans wasted probably an hour of everyone's time overall on the phone bouncing me around departments, unable to comprehend my request, trying to upsell and pitch irrelevant services, applying contextually inappropriate talking scripts while never approaching what I was asking them in the first place. Giving up on those brainless meat bags and engaging with their chat bot, I was able to resolve what I needed in 10 minutes.

They are 100% engineers and 100% engineers have no ability to adapt to other professions. Coding is dead, if you think otherwise then I hope you are right! But I doubt it because so far I have only heard arguments to the counter that are obviously wrong and retarded.