I'm the author of Python Crash Course, and I got this exact same email this week. I was thinking of writing a public response as well, because any attempt to sincerely answer these questions takes something along the lines of a full post. It's also worth a public response because many people who are getting into programming for the first time right now are asking variations of these same questions.

> Do I think that AI enables people to develop faster than they can keep up?

Absolutely. That's the core of this person's email, and everyone else who asks similar questions. Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP. Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.

I don't think anyone has clear answers to all the questions brought up in this email. I think people can learn faster than they used to, because they can make connections between different areas faster than they used to. But it requires skill and discipline in how you learn, and how you work. You have to intentionally build your understanding as you build your projects.

I answered this to myself - stop worrying about LLMs. It's pretty simple: due to Curry-Howard isomorphism, programming languages are just notations for some type of formal logic.

Now ask yourself a question, what language do you want to maintain the programs in? Do you think natural language is going to be easier and more maintainable than formal logic?

The answer is no. So you need programmers, people who can read the formal description and adapt it to new requirements.

LLMs are amazing technology, but the truth is - natural language just kinda sucks. Therefore, you don't really need them (see also https://en.wikipedia.org/wiki/AI_effect ).

I think people love LLMs for the same reasons they love magicians. But just like the magician employs a hidden trick, LLM just runs some algorithm you don't see or understand.

So worrying about LLMs taking programming job is kinda like worrying that a magician will take a warehouse worker job, because they can levitate stuff. Meanwhile, we already have automated programmer - it's called a compiler.

I'm a software engineer, I do software development but also system maintenance, and I do handle networking and telephony systems, and work with some juniors. Working with AI is problematic. It can speed up you but at the same time delay you. For the system maintenance part sometimes you need to do a lot of stuff fast and in various machines and you can't just count on a cloud based AI oracle (that takes time) to do your job for you. And the same time, the more you use it as a oracle, the less competent you get. If you are an expert, I would say in any area, you do benefit from using AI as a tool but it easily can become a double edged sword and make you less proficient. For juniors, it can make them rapidly produce stuff that is impressive and works ok for sites and some visual stuff, but it's impossible for a junior to become an expert if they get stuck in the AI using loop. For AI to cause a clean impact, I would say that we would have to live in a world where software engineering didn't matter. That is, the choice of databases, high availability systems, the programming languages themselves.

To me software engineering was often about: how do we structure the project so that the crappy code the other students/co-workers write don't break everything?

Not because everyone writes bad code. They do, at-least the do first time you read their code. You only think someones code is decent when you spent 3 hours trying to refactor their PR, and realized that the compromises they made were perhaps reasonable. (This is an important lesson to learn)

Whether code written by others is poor or not is also besides the point. You cannot keep everything in a large project in context (biological or not).

Software engineering (not computer science) is about: managing complexity. Structure your project in layers or abstractions or packages or silos or verticals or objects or whatever.

But break complexity into bits, so that everything isn't in mind all the time.

Nothing new about that. And poor engineering can be papered over with hard work. It's just easier to reach the point where poor engineering really bites ;)

“I built a thing with AI and I don’t understand it. I want to make changes and fix things and have no ability to theorize why it fails or how to fix it.”

Oh my. See, you have to be able to program it yourself before you can build it with an LLM. Otherwise you have no way of judging the output. AI isn’t going to make you a programmer.

Learning to program is.

Interesting article. My advice is to do it the old fashioned, hard way. There’s no royal road to knowledge, skill, and learning.

"The same kind of argument was used when China was admitted to the World Trade Organization. And indeed, lots of new jobs were created, just not in the Western world."

China's entry into the WTO is really not a good evidentiary example for AI causing mass unemployment. Unemployment in the U.S. had already been increasing at the time, peaked soon after, decreased to well below the point it had been at China's entry, and only went up again during the Great Financial Crisis, which had nothing -- or at least very little -- to do with competition from China. That's not to say that jobs weren't lost, even en masse, but they were replaced, and U.S. unemployment has been near record lows in recent years. China's WTO entry is a supporting point, not a counterpoint, to the idea that jobs lost to AI will be replaced by new ones.

https://fred.stlouisfed.org/series/UNRATE

This is an issue that's very real for me right now because I'm in the middle of teaching my own kids programming, and we've been working on it for years at this point. I'm watching AI seemingly invalidate the premise behind learning all of it. It's been a pretty depressing change to be honest, because I love programming and watching this happen is hard.

So, I've changed my approach with my own teaching. I'm having them do three things that I'm hoping will prepare them to work in the world they're going to be entering soon:

1. Always have a handmade project going, and work on it without AI assistance even if it's painfully slow.

2. When working with AI, treat it as a compiler that operates on data structures, algorithms, and architectural requirements rather than source code. You have to understand the theoretical pieces of what you're building before you instruct it to assemble them.

3. Use the AI as a powerful tool to grow your own knowledge of algorithms and troubleshooting. Whenever a problem crops up, it's an opportunity to come up with a few hypotheses of what the actual issue is. Don't let the model do it first. I have them actually write these down in our custom kanban tool as issue cards, and then they use the model to investigate how close they came to the true issue.

I'm hoping this will give them something similar to my experience of debugging over a lifetime of coding. The knowledge that seems to be most valuable that I bring to the table when coding with AI is in recognizing quality/maintainable code architectures, and "seen that before" debugging experience.

We just started this so I don't have much in the way of results yet, and it feels risky to even allow it into the curriculum. I don't think that it makes sense to hide from it though, so this is our best shot.

> After months of refactoring I had an uncomfortable realization: I may have built a system that is above my own level of understanding. When everything works, that gap is almost invisible. When it doesn't, it becomes very real.

> "Sometimes I genuinely don't know what to do next without asking another model. That made me wonder whether I spent a year building a product, or partly building the appearance of one: something sophisticated enough to work, but which I don't yet understand deeply enough to truly own

This is always the reality for a sufficiently complex system. We only have an illusion of understanding

Now, more specifically about this feeling, it’s the way a lot of managers feel as well. They can only ask others to fix/change things, and they don’t really understand how/why things break in the code. Even if they lead the whole team to build the product

My earnest, non-sarcastic advice to anyone considering learning to code is to find something else that interests you.

While there is possibly some time left before the software industry implodes, hobbyist software will also get steamrolled so I would in the strongest terms possible guide someone to find something that makes them happy and to pursue it.

The software industry as it exists today is a sad bag of regret and disappointment being papered over by opportunists of the worst kind.

Save yourself the trouble.

I'm doing this. After getting started with LLM coding, I became super interested in learning to code, just out of passion. I walked out of engineering thinking physics was elite, but now I understand how passionate I am about building things, and how boring quantum mechanics was. Better late than never.

I've been thinking about this in the context of learning new languages and tech. In pre-LLM days it was fun to sometimes try to implement a new idea in a new language or stack and build up an understanding by trial and error. You'd have to accept that it will be slower to get going than a familiar set of tools and maybe only trade out one old tool at a time in this way.

Now the pace of dev with something new is so rapid and fun that it's hard to not skip even basic things with a new stack. I swapped postgres (old reliable) for clickhouse (first use) in a project and saw a massive speedup of my workloads, but I really have to go down the socratic rabbit hole to understand why and even then it's a different level of understanding vs having to read the readme, quickstart, install it myself, rewrite queries by hand. TBH though, pre-LLM I probably would have just plodded along with postgres and built a hacky auto-indexer thing, so in a way the agentic coding helps me explore more territory but encourages less depth.

No strong conclusions. Like OP, I'm just spitballing / trying to understand this new world too.

I am starting to see how many developers actually need to re-learn programming in the age of LLMs.

A while back Claude went down in the middle of a somewhat frantic initial deployment of a product to production at a company where a friend of mine works. And suddenly nobody was able to do anything. Because nobody had actually read the code and had no idea how it worked.

So essentially: much of their day to day work now depends entirely on the availability of a couple of frontier LLMs.

Sorry, programming is still fun. LLMs can't change that.

> Still, I doubt that it's possible to significantly speed up human learning. The bottleneck is hardly the teachers nor the materials, but how fast a human brain can absorb new knowledge.

I completely agree with it. LLM might be able to 10x the number of PRs, and maybe that is actually is fine for the company because it doesn't care too much about verifications and such. It just wants to ship something that works. But individuals still learn at approximately the same speed. My brain still needs to hit some walls, scream at itself and assimilate the failure and success of my past, to actually learn something new. LLM does help by serving as a very good search engine if I can't Google it easily, but no more than that.

I'm also very happy that OP said "I don't know" a few times.

>I may have built a system that is above my own level of understanding.

I feel like that about a lot of code i did myself; If you don't structure things very logically and really think about your comments; A few months or years will leave you with a hell of a learning curve to understand what you created.

AI actually helps with this, if you have the right prompt injections. I feel like the correct way to handle AI is to take a step back in abstracting problems.

I'm very use to collapsing subroutines to make things readable, maybe even further back from this though, the issue is words become too vague to be useful at these scales.

(sorry pasting from 4 days ago but IMHO perfect fit)

The same reasons we keep on teaching kids to read, write, do math, sketch, take photos, etc ... because it is fun, empowering and important.

Most of them will never become professional actors, authors, mathematicians, artists, photographers, etc ... and yet they will rely on those skills, on their own or combined, pretty much every single day of their lives.

https://news.ycombinator.com/item?id=49664034

one thing ive found fascinating recently was re-taking some of the best tutorials i've ever taken (catlike coding, libtcod roguelike, etc), and asking astra to just transpile them into other technologies, stacks, or languages. Including all the garden paths, false starts, and dead ends, because the tutorial author included those intentionally. I had it copy graphics across where they're a screenshot of software, and reproduce diagrams with interactivity to show how graphs/shapes/values change as inputs are varied.

Another key thing to ask it to preserve is the nature of how we are asked to edit files. Sometimes its "replace x method with this" and then an explanation, but sometimes its "change the check at the top of suchandsuchafile to handle the new method signature", which of course forces the user to follow with and try things themselves instead of blindly copy and pasting

I certainly feel I gain insight into new technologies the same way I did with the original tutorials

Worth noting before anyone gets any ideas the resulting documents are purely for ones own consumption, publishing such things would be a moral injury against society in general and the original author specifically. If they wanted it to be made, they could just do it themselves.

A good question might be: what do I want to be ? A good prompter ? It's like someone who used to bee a good chef but is now good at ordering at uber eats. Even for a junior: being a good prompter may not be enough.

We tend to think that we make a program, but (writing) the program also makes us what we are. It is what we do that defines what we are. "I think, therefore I am".

I don't see a career path for a prompter. I don't see the benefit for an organization to rely on people who don't understand what they do nor how the programs that keep the organization running works.

That being said, "the man and the machine" can be a powerful combination, like when we drive a motorbike. For me the cooperation with a LLM could work like this: if there is 50 features I write the code for 25 of them and write stubs (classes, methods) for the 25 others, with comments that will be the prompt. The AI audits what I write, gives suggestion, find blind spots and learn best practices from my code. Then I do the same kind of review on the generated code and the AI learns from my review. An AI can even, with luck, suggest a completely new way to solve a problem (see AlphaGo vs Lee Sedol move#37 in game#2) and then I learn something.

Working like that will make me better at reading code (after all Linus spend a lot of time in reading code, it is a good skill to have) while the AI gets better as well. I don't delegate everything and keep practicing, I keep myself up to date, the AI learns from me and I get peer review from the AI. And the codebase does not become a mess (=technical debt) that only another AI can maintain while token prices increases.

IMHO, I think that it could be better if the question about how to learn programming in the age of LLMs were asked to someone who is learning now by using LLMs. Someone who learned programming thirty years ago can perhaps give you only one side of the coin, whereas someone learning today from scratch using LLMs could give you good advice on what the real difficulties are and where the main drawbacks lie. Combining both views would give a better idea of the landscape.

Programming education in the LLM era will be different from what it is now. Many of the learning methods emerging now are the practices of a "good senior programmer."

But realistically speaking, choosing LLM programming ultimately means pouring out an enormous amount of code, and it's difficult to verify all of it. Common sense says that if you produce 10,000 lines in an hour, you can't read all of it, and even if you do read it, you'd have to rewrite it. The problem is that LLM code differs from human abstraction. Or more precisely, it lacks a programmer's habits, so it's hard for me to maintain.

Clearly, programming in the LLM era will be different. The problem is that I can't get a sense of what that way of doing things actually is.

I think that low-priority frontend work will probably be handled by LLMs, while only complex animation work will be handled by humans, and humans will end up working only on things like payment modules, which are hard to fix if something actually goes wrong.

LLMs are now better at optimization than most people.

i might never know what it's like to learn programming after LLMs became powerful (I started programming in ~2002). But if someone forced me to give advice to such people, I'd say just start building things and stay curious.

That means, use LLMs to build whole sites and then dig in where you are curious. Look at the code, ask your LLM how it works and keep digging until you understand how the program is constructed. A benefit is that you're looking at a REAL program, not a toy example. And also, if your program stops working well (bugs or perf issues), you can debug it with the LLM and start asking it to teach you why things were slow and the concepts behind it.

I think you can basically build your own on-the-fly curriculum these days and do it with a real-world example WHILE you build cool stuff.

I think the biggest barrier will be motivation - many people don't want to be curious, and they just want it to work. they won't learn anything that way.

I would argue that learning a high level language like Clojure is most productive now that LLMs exist. I'm going to make a bold prediction that imperative programming is effectively dead now. LLMs are very good at writing the implementation details, dealing with syntax quirks, and the boilerplate.

What you still have to understand are high level concepts like which algorithm is appropriate to use for a particular problem, or which data structure is a good fit for the data. How to organize your logic at scale and how data flows through the system. These are the kinds of things you need to be able to do to evaluate whether a solution an LLM came up with is sound or not.

So, you still need to learn and practice writing code to develop the intuition for these things, but you don't really need to worry about the nitty gritty of it. And a language like Clojure is a perfect fit here.

Finally a thread to traumadump my anxieties!

I have been trying to learn programming unsuccessfully for many years (I still ocasionally get a burst of energy, try something, then eventually abandon it halfway). In the end, I just accept that I don't have the kind of thinking that makes this effort enjoyable and I cannot achieve anything good.

But, to be fair, LLMs also don't solve any problems for me in any meaningful way. I have to do a little bit of very simple coding at work and I would say that I struggle with LLMs as much as I do when I try to solve them by myself. The code works in a moment but when it gets extended, it breaks, I spend a lot of time troubleshooting. Last week I had to rewrite the code myself as my attempt to prompt fixes with LLMs just kept adding bugs -- I can't say my rewrite is any good (I need to traverse graphs and I don't know how to do it properly so I just used whatever algorithm I found in a book lol), it will probably break the next week when I need to change it or add something but I hope at least I'll be able to fix it faster as I have roughly an idea what's happening.

I haven't measured how much time I spend on things with or without LLMs but the subjective experience is pretty poor -- I work in an "engineering-heavy" company, the constant feeling of not understanding my own work among people who have master things that are 10x more complex is pretty depressing. When I program something poorly, I can at least explain what I did and what my idea was, even it was a bad one, waking up to build failures and spending an entire day relearning my own project is not good, man.

As for the obvious argument -- "you're using it wrong" -- I might be? I did try to learn prompting and I don't think I do any obviously stupid stuff like specifying a persona. At this point I feel half-insane as a frequent sentiment is that non-programmers can generate code for functioning software with LLMs, perhaps it's low quality code but it works. Except for me -- a non-programmer who fumbles it every day! I don't even need anything complicated -- they're Python extensions for a Sphinx project!

I still differentiate between code monkeys, coders, programmers, hackers and software developers/engineers. Software development is not coding alone, you need to follow best practices and principles to create a stable, maintainable and trustworthy product, one that _you_ or your company owns. Maybe "code monkeys" (which is a minority) are replaceable. But for now, LLM cannot have a wider vision for your products future. The willingness of building something durable is totally human. To make this possible professional software developers are still mandatory and they will be for a long time. And yes, I think is it possible to learn those best practice and principle without coding. But I think this is very hard and boring.

AI LLM systems, i.e. perplexity.ai, are very good at tutoring someone about how something works, i.e. advanced math, and when done in a loop can be very useful at tutoring, better than youtube videos I've seen on the same subject. The one thing I will usually request in (in the case of math), is to suffix the prompt with "explain this in terms a 9th grader would understand", and this is good enough to explain something in simpler terms with various breakdowns that can be understood by anyone to tutor yourself in alot of subjects using this method. This can be applied to programming, auto repair, construction, almost any subject at this point.

My biggest issue with halting AI progress right now is we are in a dangerous place where AI is only just good enough to be dangerous. So I see an argument to continue development until its competent to depend on.

I have a hard time understanding the problem here. I view ai as a tool. Like a steam shovel, electric drill, etc. You can pick up any tool, and try to use it. With the the drill, you’ll have modicum of success, until the drill spins in the chuck. Then you’ll learn to tighten the chuck more, and have more success. Try to solo on a steam shovel with no training, and there will likely be trouble. Vibe coding without understanding underlying syntax is similar.

>> "About a year ago I became fascinated by AI-assisted programming. Despite having no formal CS background, with LLMs I managed to build a fairly large TypeScript/JavaScript system [...] At first it felt almost magical: [...]

It's comical how these people claim first person: "I built". Look: having a LLM shit you some code is in no way different than paying some third world country dude on Upwork 5 bucks to build you "a Facebook clone" or whatever preposterous claim of grand software. In fact at this point it's cheaper to pay that third world country team than a LLM.

And yet before the advent of LLMs noone ordering a job on Upwork was delusional enough to claim "I built it". Although it's the same magical process, like the magic ring in fairy stories. You put the ring on your finger, rotate it and make a wish and the ring makes it appear. Well, for 5 bucks or something.

But nowadays every half witted retard with 50 bucks to spend goes to a LLM and has some "Facebook clone" spitted out and claims "I BUILT THIS!". You haven't built shit, and you know nothing!

Fortunately, reality strikes sooner or later but boy am I tired of Lord of The rings claims.

A good place to start:

https://sarabander.github.io/sicp/

Recently I start to do some hobby project by learning Common Lisp to understand more about the libraries I used on app

I read the document and sometimes use LLM as a quick search engine because I am tired of every query on google that use AI to summarize

The project goes slowly but seems the basics I grasped over the years help a lot

So perhaps it still worth to learn by hand with trial and fail

I agreed with the author that one must learn deep above the abstraction and I truely think programming still a thing even the agentic coding is getting powerful

"...I'd seriously consider learning carpentry, metalworking, gun-smithing..."

Those sound like hobbies? Outside of apocalyptic/utopian scenarios that is.

>> Yes, new jobs were created, but often not for those people who lost their jobs

This is the most obvious thing so many people who claim "new jobs were created" miss.

Yeah sure, new jobs will be created. But not for 90% of those who lost them (and most likely not for the one who claims this). You either won't have time, or energy or else to learn it and compete etc. Sure a small % of people will transition, a massive amount will not.

As long as you have critical thinking, it's fine.

So I would say it accentuates the gap between good developers and bad ones.

A sharp sense for logic and causality etc is what differentiates.

I am curious that would there be any new programming language being invented in the age of LLMs, as LLM is about probability and need to trained on a large dataset to perform. It looks like the incentive is less while it costs more to create a new programming language.

It was much easier in the Age of Empires II Expansion Edition. Miss those times, too... :-/

For those struggling with the idea of staying relevant as a human programmer, think about other jobs first. What jobs are there today that humans work on, despite technology making humans obsolete?

Mostly humans are replaced at physical labor (although even then not entirely). Human computers and punchcard operators, switchboard and telegraph operators, typesetters/letterpress/linotype operators, draftsmen, photo retouchers, film developers and projectionists, pneumatic tube operators, record-pressing/mastering engineers, the horse-drawn transportation industry, handloom weavers and embroiderers, coopers, wheelwrights, blacksmiths, key cutters, bookkeepers, payroll clerks, proofreaders... This is just a tiny list.

Technology replaces the least efficient parts first, and humans remain to do things that're harder or more expensive to automate safely or reliably. A human who used to build something by hand, transitions to a human who operates a machine to build, then designs or prepares work for the machine, and finally maintains the machine that does it all. For many automated jobs, people now perform maintenance, operations, or design work, that could be done by machine, but we either require or prefer a human do it.

For those remaining jobs, you often still need special skills. But it's no longer a herculean task to perform the work, and the jobs are more specialized and less skilled in general. We still need those jobs, or those automated things simply wouldn't function. Someone has to build them, someone has to maintain them, and someone has to operate them, and each of those requires skill.

So human programmers, systems engineers, designers, architects, operators, etc, will all be very necessary over the next 50 years. You will still need to know the languages, compilers, networks, computers, etc work. You just won't be manually typesetting anymore, or manually weaving the digital cloth. Someone will need to get into the guts of the machine from time to time.

Learning to program is learning to think and still important to learn.

The current state of vibe or assisted / automated coding is still improving, it sometimes still can end up like cowboy coding gone wild.

I said this in different ways before and got shoveled because of the way I said it:

None of us know how to farm, not even the chefs who cook for us at a restaurant or fast food joint, but we eat every day and nobody's going around making people feel guilty about not knowing how to till soil and sow seeds..

In programming and other creativity, most people's skills will [have to] change/evolve into managing, directing, dictating, knowing what you want, describing it, and focusing on the end product and iterating,

instead of wrestling with why the f is a string a pointer to a pointer to a character

just like we don't track the phases of the moon and seasonal rainfall before we can have a nice salad to eat.

Feels like the former classic software engineers will go deeper into the technical stack, moving away from frontend/design and flashy things

I think a person who still knows how to code manually, learning from raw documentation and trial and error can hold massive leverage over people who don't.

How much programming knowledge do you think someone should know before they can comfortably say they are a solo developer? (in this age of AI coding)

> You can add a comment to this post by sending me a pull request.

Interesting.

I think bill gates summarized it pretty well in a recent letter [1]. There are pro's and con's to every new technology. Learning can be greatly accelerated with the use of llm's but you have to use them the right way. Just like calculators help further down the line, they do not help you when you are still trying to learn the basic concepts of arithmetic. I personally think I have found a way of working with llms that really accelerates getting stuff done while i am still able to learn. It means reading more, and (although I hate this in part) reading generated text. What is infuriating is when I suspect people writing to me with generated text, it is insulting and should be banned. Makes me want to spend more time offline (probably a good thing in my case).

[1]https://www.gatesnotes.com/home/home-page-topic/reader/a-tur...

If you were an average tailor in 1700s, you would have to transition into operating sewing machines in a sweatshop. Same for coders, time to transition into the intellectual sweatshop, this one at least seems to be more comfortable.

Coutures are still hand made by tailors, a lot of it hand sewn without a machine. It’s the same with LLMs, GPT Astra max thinking and it still mostly looks and feels like Slop. That slop is probably fine for 90% of software products but not for 10% of remaining high quality software. Decide which part you think you can / want to join.

ai will mitigate but not fully remove coders

I think it's still important for young people to learn coding without the LLM. they need to see the little pieces before they can build big structures. It will be like calculators, just on a bigger scale: you learn how arithmetic works, and then you rely on the calculator when you are multiplying large numbers.

My guess is it will probably take some time to incorporate LLM use into education. People who are graduating right now have a problem, being between two worlds. Those graduating in a few years might have chance to figure out what to do.

> I may have built a system that is above my own level of understanding

If I venture into an unknown area, I end up where the letter-writer ends up when he is visiting programming. Suppose I am curious about an advanced math topic, like Navier-Stokes. The LLM's answer to the news about the new advance last week is strewn with words I don't understand. Asking about anything produces another essay with more things, a loop that never closes. If it were my specialist area, I imagine I would eventually hit some point where the explanation connects to something familiar.

I think this is the wall people run into when they don't have the fundamentals. You eventually get to a point where the machine is asking you for decisions that you won't know the consequences of, and when you are trying to clarify, you end up in a massive rabbit hole. It's not that different from asking a real expert about their area, they will eventually ask you to clarify something that means something to them, but not to you.

I learned programming the slow way. I would run into phrases like "memory barrier" or "green thread" and find an article using the keywords, which led to more searches, which led to more...

There are also many false dawns. Early on, after some success writing some trading strategies, I thought I had it, in the sense that I would be able to write any program required. But it wasn't true, I would run into an iceberg from time to time. Huge areas of knowledge that I hadn't come across.

Obviously I'm not claiming I finally know everything, but LLMs have arrived at a very convenient time for me. For the things I build, there is rarely anything that I don't understand at a fundamental level. When it asks me something, it's an incidental question: what decision should we make? What are the superficial changes that are needed to fit the architecture to the desired product?

I am essentially using LLM as a very quick junior, who knows how the OS works well enough to compile things and analyze logs. These are things that would take a lot of attention in the old days because they can break on very small errors, but the direction was known from the start, and thus for me (having paid the learning cost already) it is just a matter of waiting for the AI to get the code into the desired state.

I have a somewhat usable experience. I was asked to build a trading system a few years ago, which would connect to certain exchanges and show an orderbook. This kind of thing is bread and butter, but writing it up at a new firm would still take weeks.

In recent engagements, I've simply declaratively told the LLM what properties I wanted to see in the solution, waited, and answered a few questions. Since the architecture is the same, there weren't a lot of real decisions. The time difference is immense.

[flagged]

[dead]

[dead]

[flagged]

[dead]

[dead]