> Traditionally, coding involves three distinct “time buckets”:
> Why am I doing this? Understanding the business problem and value
> What do I need to do? Designing the solution conceptually
> How am I going to do it? Actually writing the code
> For decades, that last bucket consumed enormous amounts of our time. We’d spend hours, days or weeks writing, debugging, and refining. With Claude, that time cost has plummeted to nearly zero.
That last part is actually the easiest, and if you're spending inordinate amount of time there, that usually means the first two were not done well or you're not familiar with the tooling (language, library, IDE, test runner,...).
There's some drudgery involved in manual code editing (renaming variable, extracting functions,...) but those are already solved in many languages with IDEs and indexers that automate them. And so many editors have programmable snippets support. I can genuinely say in all of my programming projects, I spent more time understanding the problem than writing code. I even spent more time reading libraries code than writing my own.
The few roadblocks I have when writing code was solved by configuring my editor.
I have a feeling that people who got bogged down in step 3 were the kind of people who write a lot of wordy corporate boilerplate with multiple levels of abstraction for every single thing. AKA "best practices" type coding.
For me the most important part of a project is working out the data structures and how they are accessed. That's where the rubber meets the road, and is something that AI struggles with. It requires a bit too high a level of abstract thinking and whole problem conceptualization for existing LLMs. Once the data structures are set the coding is easy.
> Once the data structures are set the coding is easy.
I don't always find this, because there's a lot of "inside baseball" and accidental complexity in modern frameworks and languages. AI assist has been very helpful for me.
I'm fairly polyglot and do maintenance on a lot of codebases. I'm comfortable with several languages and have been programming for 20 years but drop me in say, a Java Spring codebase and I can get the job done but I'm slow. Similarly, I'm fast with TypeScript/CDK or Terraform but slow with cfndsl because I skipped learning Ruby because I already knew Python. I know Javascript and the DOM and the principles of React but mostly I'm backend. So it hurts to dive into a React project X versions behind current and try to freshen it up because in practice you need reasonably deep knowledge of not just version X of these projects but also an understanding of how they have evolved over time.
So I'm often in a situation where I know exactly what I want to do, but I don't know the idiomatic way to do it in a particular language or framework. I find for Java in particular there is enormous surface area and lots of baggage that has accumulated over the years which experienced Java devs know but I don't, e.g. all the gotchas when you upgrade from Spring 2.x to 3.x, or what versions of ByteBuddy work with blah maven plugin, etc.
I used to often experience something like a 2x or 3x hit vs a specialised dev but with AI I am delivering close to parity for routine work. For complex stuff I would still try to pair with an expert.
> I have a feeling that people who got bogged down in step 3 were the kind of people who write a lot of wordy corporate boilerplate with multiple levels of abstraction for every single thing. AKA "best practices" type coding.
Or they're the kind of people who rushed to step 3 too fast, substantially skipping steps 1 and/or 2 (more often step 2). I've worked with a lot of people like that.
While probably not useful for everyone, the best method for myself actually leverages that.
I am using a modified form of TDD's red/green refactor, specifically with an LLM interface independent of my IDE.
While I error on good code over prompt engineering, I used the need to submit it to both refine the ADT and domain tests, after creating a draft of those I submit them to the local LLM, and continue on with my own code.
If I finish first I will quickly review the output to see if it produced simpler code or if my domain tests ADT are problematic. For me this avoids rat holes and head of line blocking.
If the LLM finishes first, I approach the output as a code base needing a full refactor, keeping myself engaged with the code.
While rarely is the produced code 'production ready' it often struggles when I haven't done my job.
You get some of the benefits of pair programming without the risk of demoralizing some poor Jr.
But yes, tradeoff analysis and choosing the least worst option is the part that LLM/LRMs will never be able to do IMHO.
Courses for horses and nuance, not "best practices" as anything more than reasonable defaults that adjust for real world needs.
I would imagine that's why they had "best practices" in quotes. Lots of enterprisey things get pushed as a "good practice" to improve reuse (of things that will never be reused) or extensibility (of things that will never be extended) or modularity (of things that will never be separated).
Enterprise development has particular problems you won't find in other environments, for instance having hundreds of different developers with widely varying levels of skill and talent, all collaborating together, often under immense time and budget pressure.
The result ain't going to be what you get if you've got a focused group of 10x geniuses working on everything, but I think a lot of the aspects of "enterprise development" that people complain about is simply the result of making the best of a bad situation.
I like Java, because I've worked with people who will fuck up repeatedly without static type checking.
> for instance having hundreds of different developers with widely varying levels of skill and talent
That's a management problem. Meaning you assess that risk and try to alleviate it. A good solution like you say is languages with good type checking support. Another is code familiarity and reuse through frameworks and libraries. A third may be enforcing writing tests to speed up code review (and checklist rules like that).
It's going to be boring, but boring is good at that scale.
I can attest to that and see it as the reason why Angular is still so popular in the enterprise world - it has such a strong convention that no matter the rate of staff rotation the team can keep delivering.
Meanwhile no two React projects are the same because they typically have several dependencies, each solving a small part of the problem at hand.
Nah, these are the people who don't know the difference between a variable and a function call and who think FizzBuzz is a "leetcode interview problem".
same, the amount of work I have to put into thinking of what to say to the llm is the same or more work than just telling the compiler or interpreter what I want (in a language I'm familiar with), and the actual coding is the trivial part. in fact I get instant feedback with the code, which helps change my thinking. with the llm, there's an awkward translating for the llm, getting the code, checking that it might do what I want, and then still having to run it and find the bugs.
the balance only shifts with a language/framework I'm not familiar with.
I think it’s useful to think of LLMs performing translation from natural language to a program language. If you already speak the programming language fluently, why do you need a translator?
I agree for method-level changes, but the more you’re willing to cede control for larger changes, even in a familiar language, the more an LLM accelerates you.
For me, I give Gemini the full context of my repo, tell it the sweeping changes I want to make, and let it do the zero to one planning step. Then I modify (mostly prune) the output and let Cursor get to work.
And the article is overstating it as well. My confidence in the LLM's ability to reduce the "how" part is primarily based on "am I doing something the LLM is good at?". If I'm doing HTML React where there's a million examples of existing stuff, then great. The more novel what I'm asking is, the less useful the LLM becomes and the more stuff I need to handcode is. Just as with self-driving cars, this is a challenge because switching from "the LLM is generating the code" to "I'm hand-tweaking things" is equivalent to self-driving disconnecting randomly and telling you "you drive" in the middle of the highway. Oh and I've caught the LLM randomly inserting vulnerabilities for absolutely no reason (e.g. adding permissions to the iframe sandbox attribute when I complained about UI layout issues).
It's a useful tool that can accelerate certain tasks, but it has a lot of sharp edges.
> Oh and I've caught the LLM randomly inserting vulnerabilities for absolutely no reason (e.g. adding permissions to the iframe sandbox attribute when I complained about UI layout issues).
Yeah, now get the LLM to write C++ for a public facing service, what could possibly go wrong?
I think React is one of those areas where consistency is more important than individual decisions. With a lot of front-end webdev there's many right answers, but they're only right if they are aligned with the other design decisions. If you've ever had to edit a web page with three different approaches to laying out the CSS you know what I mean.
LLMs _can_ do consistency, they're pretty good continuing a pattern...if they can see it. Which can be hard if it's scattered around the codebase.
Consistency is why frameworks and libraries exists. Once you start to see consistency in your UI views, that's a good sign to further refine it into components and eliminate boilerplate.
I think you're overly painting that process as a waterfall method. In reality, i think its more of a loop. You do the loop a bunch of times and the solution gets better and better. The act of coding sometimes exposes a lot more of the requirement questions you didn't even know to ask in the first few steps.
So anything that can let you iterate the loop faster is good. The analogy is kind of like if you can make your compile and tests faster, its way easier to code. Because you don't just code and test at the very end, you do it as part of a thinking loop.
You can get a lot of stuff designed before having to start the loop, just like you can get the boilerplate code written (or use a framework), before writing any business logic.
Writing code to find specs is brute-forcing the solution. Which is only useful when there's no answer or data (kinda rare in most domains). Taking some time to plan and do research can resolve a lot of inconsistency in your starting design. If you have written the code before, then you'll have to refactor even if the program is correct, because it will be a pain to maintain.
In painting, even sketching is a lot of work. Which is why artists will collect references instead, mentally select the part they will extract. Once you start sketching, the end goal is always a final painting, even if you stop and redo midway. Actual prototyping is called a study and it's a separate activity.
I agree, they are very much exaggerating both time spent writing code, as well as the amount of time LLMs shave off. LLM coding very much does NOT take “near zero time,” I would argue that sometimes it can take the same amount of time or longer, compared against simply knowing what you are doing, with tools you know how to use, referring to documentation you know how to interpret, understanding the systems around, the business around, what team A and C need in two quarters so we better keep it in mind… etc.
I had the weirdest experience the other day. I wanted to write an Expo React Native application - something I have zero experience with (I’ve been writing code non-stop since I was a kid, starting with 6502 assembly). I’ve leaned heavily on Sonnet 3.7 and off we went.
By the end of the day (10-ish hours) all I got to show was about 3 screens with few buttons each… Something a normal React developer probably would’ve spat out in about a hour. On top of that, I can’t remember shit about the application itself - and I can practically recite most of the codebases that I’ve spent time on.
And here I read about people casually generating and erasing 20k lines of code. I dunno, I guess I am either holding it wrong, or most of the time developing software isn’t spent vomiting code.
Interesting. I had the exact opposite experience recently.
I've also been writing code for a long time, did the 6502 assembly thing way back when, and lots since then. For this current project I wanted to build a web app with a frontend in Angular and a backend in Java 21 relying on javalin.io for the services layer. It had a few other integrations as well - into a remote service requiring OAuth and also into subtlecrypto. After less than 10 hours I had a fully functioning MVP that was far superior to anything I could have created without an assistant. It gave me build files, even a test skeleton. Restyling the UI or reflowing the UX to include confirmations, additional steps, modals, ... was really easy. I just had to type it, and those changes would get made. It felt like I was "director of development" for a day.
Well... In my case the scaffolding was done by the Expo template, used Expo libraries for social login and I wrote the Expo API backend functions.
Was it productivity boost for me - yeah, cause I know mostly shit about React. But as an end result it just felt very underwhelming. Discussing it today with my brother (who lives and breathes FE) it apparently was.
I guess I was just expecting... I dunno... more - people are claiming nX productivity boosts, and considering how the UI is mostly boilerplate...
If it were, the median e.g. business analyst should be getting paid significantly more than the median software engineer. That's not what the data shows, however.
>I can genuinely say in all of my programming projects, I spent more time understanding the problem than writing code.
This is almost trivially true for anyone who understands the problem via writing code, though.
You're assuming only the last part is what software engineer do.
The business analyst mostly just scratch the top half of the first part.
But I do encourage them to go vibe coding! It's providing a lot of entertainment. On off chance, they would become one of us and would be most welcomed.
I'm not, but any time spent on #3 is time not spent on #1 and #2. So why wouldn't a profession specialized in the harder tasks make more money?
My real point is claiming #3 is the easiest is just silly. It's obviously much easier to come up with good business ideas in the abstract than to bring them into being. The mixture works because software as a business is an O-ring problem. These 3 tasks are not cleanly separable, they're all part of a feedback loop together.
> What do I need to do? Designing the solution conceptually
That's not respecting #2, which still fall squarely in engineering profession.
The design of the solution are necessarily technical, otherwise it's just throwing a bunch of concept and big words to sounds cool and leads to nowhere.
The outcome of this solution would then go back and influence #1 which is the behavior that customer see. If Steve Jobs couldn't fit all of his components into his iphone then it wouldn't have existed, and he might have to settle for something less, like an ipod.
Obviously this would all exist in a ring and that's why everyone is continuously employed and mostly not fired once the product gets released.
I spend most of my time talking to stakeholders and BAs to help them better understand what their actual problem is instead of coming to me with "we want this" :/
Writing code is the trivial part, yet it can be quite time consuming. I know what I want, so I don't want to care about the trivial minutae, same as I care very little what machine code falls out of my compiler. LLMs aren't capable yet to enable this easily and reliably, but they present a (often useful) glimpse.
It's a real job - but more in IT and less software development. IT departments in many places prefer to do the buy rather than build since build is more expensive for them.
I'm somebody who used to think your way until very recently (long-time vim user, fast typer, etc.).
I'd recommend you give `aider` specifically a try. It's slowly taken over more and more of the "what" and "how" buckets outlined in the article, especially for large-surface-area code bases.
It turns out, for me at least, there is a big mental activation hurdle between "what" and "how". I need a lot of focus time to pivot between "what" and "how" efficiently, especially for work that spans large parts of the codebase, and work that I'm not super excited about doing. Using `aider` has lowered this activation threshold dramatically. It's made "writing code" about as simple as talking about a technical solution with an intelligent colleague.
I usually follow the format (1) describe the context of the app / problem you're trying to solve (2) describe what you know the solution will look like (3) ask it for clarifying questions / if it needs any examples or context to know the problem space better, and if the solution makes sense / do they see any issues with it? (4) ask it to outline the solution in greater detail, do not write code (5) add any clarifications, now do the thing.
i.e. it's kind of similar to interacting with a super fast, eager, indefatigable junior engineer. Sometimes it misses things or misunderstands, but not nearly enough to make the juice not worth the squeeze. These days, I'd say I spend more time reading/editing claude-generated code, writing commit messages, and managing deployments than I do writing code. It's a higher level of abstraction and I get way more leverage out of the deal. The code I'm writing is, on balance, better than the code I wrote before. It took maybe a few months to get here, but I'm happier for giving it a shot.
For many developers the first couple of items isn't a thing, we're just given requirements and the designs. At most, you can point out issues and do time estimates.
For my current job coding is 90% of my time. The rest is meetings, deployments, ticket management. Most of the time coding isn't particularly hard, but it sure consumes lots of time. I've had many days with 1000+ line diffs.
> With Claude, that time cost has plummeted to nearly zero.
not sure if anyone knows. how good would a bigquery-sql to scala parser generated code would be? can i use it without having to dig into generated code?
How do you understand the problem without writing any code?
It's possible that people's experiences are different to yours because you work on a specific type of software and other people work on other specific types of software.
By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is more concrete and can highlight mistakes like when there's a gap in your understanding vs spots where details matter more specifically.
At many big tech companies I've worked out, an abstract design proposal precedes any actual coding for many tasks. These design proposals are not about how you lay out code or name variables, but a high level description of the problem and the general approach to solve the problem.
Expressing that abstract thinking requires writing code but that's the "how" - you can write that same code many ways.
> By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is more concrete and can highlight mistakes like when there's a gap in your understanding vs spots where details matter more specifically.
The whole argument behind TDD is that it's easier to write code that verify something than actually implement the code. Because it only have the answer, not the algorithm to solve the question.
So for any code you will be writing, find the answers first (expected behavior). Then add tests. The you write the code for the algorithm to come up with the answer.
Static typing is just another form of these. You tell the checker: This is the shape of this data, and it warns you of any code that does not respect that.
And an even stronger approach than TDD would be to develop a formal proof in something like Coq. At some point you have to define your algorithm and it’s easier when you actually have some inkling of how it would work rather than just trying to blindly get a test suite to pass.
If you haven't solved exactly the same problem before, specifying a solution before writing code is a bad idea imo. More often than not, it turns out that the prematurely defined general approach isn't very optimal.
Which points at a pretty substantial limitation of LLM coding...
The solution is always out there. The code is just an automated way to get it without the error prone way of humans doing manual calculations. But sometimes, your understanding is flawed, so the code you write is not the correct way to have the solution. Which is why you have to get actual correct answers (specs) before writing code.
Correctness is not embedded in software. It's embedded in the real world.
Typically I find a novel problem domain requires roughly about 3 attempts from scratch to get a maintainable longer-term solution. However, that still requires having some idea in mind to try before just writing code. Of course you might also do some prototyping on certain subparts of the problem but there’s only so much of that that can be done and you’re still trying out what expressing high level ideas looks like / how it works.
I don’t think there’s anything where the first step is writing code. It’s like saying the first step of solving a math problem is writing down equations.
>How do you understand the problem without writing any code?
Not OP, but I find this a very good question. I've always found that playing with the problem in code is how I refined my understanding of the problem. Kind of like how Richard Feynman describes his problem solving. Only by tinkering with the hard problem do you really learn about it.
I always found it strange when people said they would plan out the whole thing in great detail and code later. That never worked for me, and I've also rarely seen it work for those proposing it.
It may be because I studied control systems, but I've always found you need the feedback from actually working with the problem to course correct, and it's faster, too. Don't be scared to touch some code. Play with it, find out where your mental model is deficient, find better abstractions than what you originally envisioned before wrestling with the actual problems.
It's not building the whole architecture before coding. It's about getting all the answers before spending time coding things that will probably have hidden bugs.
Sometimes you don't have a way to get the exact answers, so you do experiments to get data. But just like scientists in a lab, they should be rigorous and all assumptions noted down.
And sometimes, there are easy answers, so you can get these modules out of the way first.
And in other cases, maybe a rough solution is better than not having anything at all. So you implement something that solves a part of the problem while you're working on the tougher parts.
Writing code without answers is brute-forcing the solution. But novel problems are rare, so with a bit of research, it's quite easy to find answers.
>And in other cases, maybe a rough solution is better than not having anything at all.
POCs are better for customer-facing, product management driven work. This is because they can be bad at describing what they want. There's more risk of building the wrong thing.
POCs can be okay for system design or back-end work (or really anything not involving vague asks), but chances are planning and deeper thinking will help you more there because the problems you solve tend to be less subjective. Less risk of building the wrong thing.
Rough solution in this case is more like a sketch compared to a painting, a few hours of work instead a week or two. The painting can be the main goal, but a sketch can be useful for some part.
Kinda like scaling. Instead of going for Kubernetes, use a few VPS and a managed database to get your first customers.
I’ve grown weary of people repeating absolutisms they hear online, too.
As is usually the truth in practice, it’s a mess, which is why I’ve seen combinations of upfront planning and code spiking work the best.
An upfront plan ensures you can at least talk about it with words, and maybe you’ll find obvious flaws or great insights when you share your plan with others. Please, for the love of god, don’t ruin it with word vomit. Don’t clutter it with long descriptions of what a load balancer is. Get to the point. Be honest about weaknesses, defend strengths.
Because enterprise corporate code is a minefield of trash, you just have to suck it up and go figure out where the mines are. I’ve heard so many complaints “but this isn’t right! It’s bad code! How am I supposed to design around BAD code!” I’ll tell you how, you find the bad parts, and deal with them like a professional. It’s annoying and slow and awful, but it needs doing, and you know it.
By not doing the planning, you run the risk of building a whole thing, only to be told “well, this is nice, but you could have just done X in half the time.” By not doing the coding, you risk blowing up your timeline on some obvious unknown that could have been found in five minutes.
If I have any representation of the problem in front of me the mind seems to attack it all by it self. I strongly suspect someone with more (or different) experience doesn't need this or gets better results by writing out a representation.
This is true when breaking new ground, but it’s a rare occurrence. Most business problems are a few thousand years old. Yes, there were taxes paid in the ancient world.
They weren't solving hard realtime nonlinear control for hardware running on a custom ASIC in a domain only a literal handful of companies even operate in.
Not everything has been solved for ten thousand years.
> That last part is actually the easiest, and if you're spending inordinate amount of time there, that usually means the first two were not done well or you're not familiar with the tooling (language, library, IDE, test runner,...).
I'm not sure if you're familiar with modern JS frameworks.
I started my career as a developer in the 1990s and cut my teeth in C++, moving on to Python, Perl, Java, etc. in the early-2000s. Then I did management roles for about 20 years and was no longer working at the “coal face” despite having learned some solid software engineering discipline in my early days.
As an old geezer, I appreciate very much how LLMs enable me skip the steep part of the learning curve you have to scale to get into any unfamiliar language or framework. For instance, LLMs enabled me to get up to speed on using Pandas for data analysis. Pandas is very tough to get used to unless you emerged from the primordial swamp of data science along with it.
So much of programming is just learning a new API or framework. LLMs absolutely excel at helping you understand how to apply concept X to framework Y. And this is what makes them useful.
Each new LLM release makes things substantially better, which makes me substantially more productive, unearthing software engineering talent that was long ago buried in the accumulating dust pile of language and framework changes. To new devs, I highly encourage focusing on the big picture software engineering skills. Learn how to think about problems and what a good solution looks like. And use the LLM to help you achieve that focus.
I've been using it to learn Lean, the proof assistant language, and it's great. The code doesn't always compile, but the general structure and approach is usually correct, and it helps understand different ways of doing things and the pros, cons, and subtleties of each.
From this it has me wondering if AI could increase the adoption of provably correct code. Dependent types have a reputation for being hard to work with, but with AI help, it seems like they could be a lot more tractable. Moreover, it'd be beneficial it the other direction too: the more constraints you can build into the type system of your domain model, the harder it will be for an AI to hallucinate something that breaks it. Anything that doesn't satisfy the constraints will fail to compile.
Yep, same. I'm an old hand at pandas, and writing a 300 line script in pandas and asking Claude to rewrite it to polars taught me polars faster than any other approach I've used to learn a new framework.
Yep, I absolutely relate to this. ChatGPT happened to come out right when I needed to learn how to use kubernetes, after having used a different container orchestrator. It made this so much easier.
Ever since, this has been my favorite use case, to cut through the accidental complexity when learning a new implementation of a familiar thing. This not only speeds up my learning process and projects using the new tool, it also gives me a lot more confidence in taking on projects with unfamiliar tools. This is extremely valuable.
I am pretty much in the same boat, although I was never that advanced a dev to begin with.
It is truly amazing what a superpower these LLM tools are for me. This particular moment in time feels like a perfect fit for my knowledge level. I am building as many MVP ideas as quickly as I can. Hopefully, one of them sticks with users.
> So much of programming is just learning a new API or framework.
Once you're good at it in general. I recently witnessed what happens when a junior developer just uses AI for everything, and I found it worse than if a non-developer used AI: at least they wouldn't confuse the model with their half-understood ideas and wouldn't think they could "just write some glue code", break things in the process, and then confidently state they solved the problem by adding some jargon they've picked up.
It feels more like an excavator: useful in the right hands, dangerous in the wrong hands. (I'd say excavators are super useful and extremely dangerous, I think AI is not as extreme in either direction)
It used to (pre-'08 or so) be possible to be "good at Google".
Most people were not. Most tech people were not, even.
Using LLMs feels a ton like working with Google back then, to me. I would therefore expect most people to be pretty bad at it.
(it didn't stop being possible to be "good at Google" because Google Search improved and made everyone good at Google, incidentally—it's because they tuned it to make being "bad at Google" somewhat better, but eliminated much of the behavior that made it possible to be "good at Google" in the process)
Fun fact, I recently started reading Designing LLM Applications[0] (which I'm very much enjoying by the way) and it draws this exact analogy in the intro!
I swear I didn't steal mine from there, LOL. Maybe I'm on the right track if others are noticing similar things about the experience of using LLMs, though.
Yes exactly, I meant it as evidence that there is something to this insight. Also that it stuck with me in the book enough to make the connection when I saw your comment; it's that it struck me as a good point.
Also agree. I've been playing with Godot for some super simple game dev, and it's been surprisingly fantastic at helping me navigate Godot's systems (Nodes, how to structure a game, the Godot API) so I can get to the stuff that I find enjoyable (programming gameplay systems).
No, it's not perfect and I imagine there's some large warts as a result, but it was much, much better than following a bog-standard tutorial on YouTube to get something running, and I'm always able to go refactor my scripts later now that I'm past initial scaffolding and setup.
> The developers who thrive in this new environment won’t be those who fear or resist AI tools, but those who master them—who understand both their extraordinary potential and their very real limitations. They’ll recognise that the goal isn’t to remove humans from the equation but to enhance what humans can accomplish.
I feel like LLMs are just the next step on the Jobs analogy of "computers are bicycles for the mind" [0]. And if these tools are powerful bicycles available to everyone, what happens competitively? It reminds me of a Substack post I read recently:
> If everyone has AI, then competitively no one has AI, because that means you are what drives the differences. What happens if you and LeBron start juicing? Do you both get as strong? Can you inject your way to Steph’s jumpshot? What’s the differentiator? This answer is inescapable in any contested domain. The unconventionally gifted will always be ascendant, and any device that’s available to everyone manifests in pronounced power laws in their favor. The strong get stronger. The fast get faster. Disproportionately so. [1]
If you and Lebron both had mech-suits you'd be equal in strength. Actually you might find that maybe you communicate better with the machine as you've had to communicate a lot more for work and have further refined those neural patterns. So actually, I would expect those with exceptional communication skills and creativity to be the best able to take advantage of AI. In a world where functional code in any language can be spat out at 1000 tokens/s, it matters a lot more that you can communicate your vision than understanding the inscrutable byte-level architecture of ARM-64 or how to write a CUDA kernal, or how to use a static class properly.
I don't think bicycle analogy is adequate. It seems that they are more like cars. And if we follow that analogy, it suggests that the direction of the evolution will depend on whether we make our society dependent on being able to drive cars and grow fat from lack of activity or use them in a more mindful 'for purpose intended' way.
> I've been thinking about generative AI tools as "bicycles for the mind" (to borrow an old Steve Jobs line), but I think "electric bicycles for the mind" might be more appropriate.
> They can accelerate your natural abilities, you have to learn how to use them, they can give you a significant boost that some people might feel is a bit of a cheat, and they're also quite dangerous if you're not careful with them!
My personal opinion is that now experience matters a lot more.
A lot of times, the subtle mistakes that LLM makes or wrong direction that it takes can only be corrected by experience. LLM also don't tend to question its own decisions in the past, and will stick with them unless explicitly told.
This means LLM based project accumulate subtle bugs unless there is a human in the loop who can rip them out, and once a project accumulated enough subtle bugs it generally becomes unrecoverable spaghetti.
> LLM also don't tend to question its own decisions in the past, and will stick with them unless explicitly told.
Dangerous as well, is that LLMs won't (unless aggressively prompted to) question your own decisions either, in contrast to something like a mentor which would help you discover a better way, if there is one.
I've never seen anyone claim that coding LLMs are mentors, but rather junior devs there to help you. Taking them as mentors changes the task completely. LLM-as-junior-dev definitely requires you to know what you want the code to do and what you expect as quality output.
Another way to think about it is SWE agents. About a year ago Devin was billed as a dev replacement, with the now common reaction that it's over for SWEs and it's no longer a useful to learn software engineering.
A year later there have been large amounts of layoffs that impacted sw devs. There have also been a lot of fluff statements attributing layoffs to increased efficiency as a result of AI adoption. But is there a link? I have my doubts and think it's more related to interest rates and the business cycle.
I've also yet to see any AI solutions that negate the need for developers. Only promises from CEOs and investors. However, I have seen how powerful it can be in the hands of people that know how to leverage it.
I guess time will tell. In my experience the current trajectory is LLMs making tasks easier and more efficient for people.
And hypefluencers, investors, CEOs, and others will continue promising that just around the corner is a future in which human software developers are obsolete.
That's kinda obvious that's their goal especially with the current focus on coding of most of the AI labs in most announcements - it may be augmentation now but that isn't the end game. Everything else these AI labs do, while fun seems like at most a "meme" to most people in relative terms.
Most Copilot style setup's (not just in this domain) are designed to gather data and train/gather feedback before full automation or downsizing. If they outright said it they may not have got the initial usage needed to do so from developers. Even if it is augmentation it feels like at least to me the other IT roles (e.g. BA's, Solution Engineers maybe?) are safer than SWE's going forward. Maybe its because dev's have a skin in the game and without AI its not that easy of a job over time makes it harder for them to see. Respect for SWE as a job in general has fallen in at least my anecdotal conversations mainly due to AI - after all long term career prospects are a major factor in career value, social status and personal goals for most people.
Their end goal is to democratize/commoditize programming with AI as low hanging fruit which by definition reduces its value per unit of output. The fact that there is so much discussion on this IMO shows that many even if they don't want to admit it there is a decent chance that they will succeed at this goal.
And just like optimizing compilers LLMs also emit code that is difficult to verify and no-one really understands, so when the shit hits the fan you have no idea what's going on.
Is it though? Most code that LLM emits are easier to understand than equivalent code by humans in my experience, helped by overt amount of comment added at every single step.
That's not to say the output is correct, there are usually bugs and unnecessary stuff if the logic generated isn't trivial, but reading it isn't the biggest hurdle.
I think you are referring to the situation where people just don't read the code generated at all.. in that case it's not really LLM's fault.
I agree that AI powered programming can give you a boost, and the points made in the post I would agree with if they were not made about Claude Code or other "agentic" coding tools. The human-LLM boosting interaction exists particularly when you use the LLM in its chat form, where you inspect and reshape with both editing the code and explaining with words what the LLM produced, and where (this is my golden rule) you can only move code from the LLM environment to your environment after inspecting and manually cut & pasting stuff. Claude Code and other similar systems have a different goal: to allow somebody to create a project without much coding at all, and the direction is to mostly observe more the result itself of the code, that how it is written and the design decisions. This is fine with me, I don't tell people what to do, and many people can't code, and with systems like that they can build a certain degree of systems. But: I believe that tody, 21 April 2025 (tomorrow it may change) the human+LLM strict collaboration on the code, where the LLM is mostly a tool, is what produces the best results possible, assuming the human is a good coder.
So I would say there are three categories of programmers:
1. Programmers that just want to prompt, using AI agents to write the code.
2. Programmers, like me, that use LLM as tools, writing code by hand, letting the LLM write some code too, inspecting it, incorporating what makes sense, using the LLM to explore the frontier of programming and math topics that are relevant to the task at hand, to write better code.
3. Programmers that refuse to use AI.
I believe that today category "2" is what has a real advantage over the other two.
If you are interested in this perspective, a longer form of this comment is contained in this video in my YouTube channel. Enable the English subtitles if you can't understand Italian.
This is my experience as well. I've been skeptical for a long time, but recent releases have changed my mind (it's important to try new things even if skeptical). Large context windows are game-changers. I can't copy/paste fast enough.
The future is coming, but you still need fundamentals to make sure the generated code has been properly setup for growth. That means you need to know what you expect your codebase to look like before or during your prompting so you can promote the right design patterns and direct the generation towards the proper architecture.
So software design is not going away. Or it shouldn't for software that expects to grow.
I can see the usefulness of agents however for (a) some tedious refactorings where the IDE features might not reach and (b) occasionally writing a first pass of a low-value module when I am low on energy.
For the rest of stuff I feel very happy with copy-paste.
Usually when I am in the flow of writing code, I can think, write, tab away and review without breaking it. If I need a smallish (up to 100-ish lines) piece of code that I know the shape of - I would use the chat to generate it and merge it back after review.
Letting the agent rip always has led to more pain and suffering down the line :(
> The human-LLM boosting interaction exists particularly when you use the LLM in its chat form
I feel reassured to see that I'm not the only one who feels this way. With all the talk about in-IDE direct code editing, I was thinking that I was being somewhat of a luddite who feels like the chat form is the best balance between getting help from the AI and understanding/deciding how things are actually structured/working.
This may depend upon every individual, but for me "How am I going to do it" is not actually writing code. It's about knowing how I'm going to do it before I write the code. After that point, its an exercise in typing speed.
If I'm not 100% sure something will work, then I'll still just code it. If it doesn't work, I can throw it away and update my mental model and set out on a new typing adventure.
That's not true. I just wrote a similar comment about design coming first. If you've written software for awhile you just know what it looks like and which design patterns will be useful. Then when you see what your LLM says is the right code you can glance at it and see if it is even on the right track.
If you're trying to LLM your way to a new social site you're going to need to know what entities make up that site and the relationships they have ahead of time. If you have no concept of an idea then of course the LLM will be "correct" because there were no requirements!
Software design is important today and will be even more important in the future. Many companies do not require design docs for changes and I think it is a misstep. Software design is a skill that needs to be maintained.
I question how much code and what kind of code is actually going to be needed when the world is composed entirely of junior engineers who can write 100 LOC a second?
Will it just be these functional cores that are the product, and users will just use an LLM to mediate all interaction with it? The most complex stuff, the actual product, will be written by those skilled in mech suits, but what will it look like when it is written for a world where everyone else has a mech suit (albeit less capable) on too?
Think like your mother running a headless linux install with an LLM layer on top, and it being the least frustrating and most enjoyable computing experience she has ever had. I'm sure some are already thinking like this, and really it represents a massive paradigm shift in how software is written on the whole (and will ironically resemble the early days of programming).
I doubt it will come to that. Most interactions are always going to be much easier with a dedicated UI than with a chatbot. In fact, I can't think of anything I use regularly that I'd rather replace the UI with chat.
If we go with this analogy, we don't have advanced mech suits yet for this. To think an IDE is going to be the "visor", and to think copy-and-pasting is going to be jury-rigged weapons on the Mech is probably not it. The future really needs to be Jarvis and that Iron Man suit, whatever the programming equivalent is.
"Hey I need a quick UI for a storefront", can be done with voice. I got pretty far with just doing this, but given my experience I don't feel fully comfortable in building the mech-suit yet because I still want to do things by hand. Think about how wonky you would feel inside of a Mech, trying to acclimate your mind to the reality that your hand movements are in unity with the mech's arm movements. Going to need a leap of faith here to trust the Mech. We've already started attacking the future by mocking it as "vibe coding". Calling it a "Mech" is so much more inspiring, and probably the truth. If I say it, I should see it. Complete instant feedback, like pen to paper.
> How LLM-powered programming tools amplify developer capabilities rather than replace them
This is my experience as well. You have to know what you want, how to interfere if things go in the wrong direction, and what to do with the result as well.
What I did years ago with a team of 3-5 developers I can do now alone using Claude Code or Cursor. But I need to write a PRD, break it down into features, epics and user stories, let the llm write code, review the results. Vibe coding tools feel like half a dozen junior to mid level developers for a fraction of the cost.
Yep. It’s the ultimate one person team. With the human playing the role of a team lead AND manager. Sometimes even the PM. You want to earn big bucks? Well, this is the way now. Or earn little bucks and lead a small but content life. Choice is yours.
> Chess provides a useful parallel here. “Centaur chess” pairs humans with AI chess engines, creating teams that outperform both solo humans and solo AI systems playing on their own. What’s fascinating is that even when AI chess engines can easily defeat grandmasters, the human-AI combination still produces superior results to the AI alone. The human provides strategic direction and creative problem-solving; the machine offers computational power and tactical precision.
Can we stop saying this? It hasn't been true for more than 15 years.
> Traditionally, coding involves three distinct “time buckets”:
> Why am I doing this? Understanding the business problem and value
> What do I need to do? Designing the solution conceptually
> How am I going to do it? Actually writing the code
> For decades, that last bucket consumed enormous amounts of our time. We’d spend hours, days or weeks writing, debugging, and refining. With Claude, that time cost has plummeted to nearly zero.
That last part is actually the easiest, and if you're spending inordinate amount of time there, that usually means the first two were not done well or you're not familiar with the tooling (language, library, IDE, test runner,...).
There's some drudgery involved in manual code editing (renaming variable, extracting functions,...) but those are already solved in many languages with IDEs and indexers that automate them. And so many editors have programmable snippets support. I can genuinely say in all of my programming projects, I spent more time understanding the problem than writing code. I even spent more time reading libraries code than writing my own.
The few roadblocks I have when writing code was solved by configuring my editor.
I have a feeling that people who got bogged down in step 3 were the kind of people who write a lot of wordy corporate boilerplate with multiple levels of abstraction for every single thing. AKA "best practices" type coding.
For me the most important part of a project is working out the data structures and how they are accessed. That's where the rubber meets the road, and is something that AI struggles with. It requires a bit too high a level of abstract thinking and whole problem conceptualization for existing LLMs. Once the data structures are set the coding is easy.
> Once the data structures are set the coding is easy.
I don't always find this, because there's a lot of "inside baseball" and accidental complexity in modern frameworks and languages. AI assist has been very helpful for me.
I'm fairly polyglot and do maintenance on a lot of codebases. I'm comfortable with several languages and have been programming for 20 years but drop me in say, a Java Spring codebase and I can get the job done but I'm slow. Similarly, I'm fast with TypeScript/CDK or Terraform but slow with cfndsl because I skipped learning Ruby because I already knew Python. I know Javascript and the DOM and the principles of React but mostly I'm backend. So it hurts to dive into a React project X versions behind current and try to freshen it up because in practice you need reasonably deep knowledge of not just version X of these projects but also an understanding of how they have evolved over time.
So I'm often in a situation where I know exactly what I want to do, but I don't know the idiomatic way to do it in a particular language or framework. I find for Java in particular there is enormous surface area and lots of baggage that has accumulated over the years which experienced Java devs know but I don't, e.g. all the gotchas when you upgrade from Spring 2.x to 3.x, or what versions of ByteBuddy work with blah maven plugin, etc.
I used to often experience something like a 2x or 3x hit vs a specialised dev but with AI I am delivering close to parity for routine work. For complex stuff I would still try to pair with an expert.
> I have a feeling that people who got bogged down in step 3 were the kind of people who write a lot of wordy corporate boilerplate with multiple levels of abstraction for every single thing. AKA "best practices" type coding.
Or they're the kind of people who rushed to step 3 too fast, substantially skipping steps 1 and/or 2 (more often step 2). I've worked with a lot of people like that.
While probably not useful for everyone, the best method for myself actually leverages that.
I am using a modified form of TDD's red/green refactor, specifically with an LLM interface independent of my IDE.
While I error on good code over prompt engineering, I used the need to submit it to both refine the ADT and domain tests, after creating a draft of those I submit them to the local LLM, and continue on with my own code.
If I finish first I will quickly review the output to see if it produced simpler code or if my domain tests ADT are problematic. For me this avoids rat holes and head of line blocking.
If the LLM finishes first, I approach the output as a code base needing a full refactor, keeping myself engaged with the code.
While rarely is the produced code 'production ready' it often struggles when I haven't done my job.
You get some of the benefits of pair programming without the risk of demoralizing some poor Jr.
But yes, tradeoff analysis and choosing the least worst option is the part that LLM/LRMs will never be able to do IMHO.
Courses for horses and nuance, not "best practices" as anything more than reasonable defaults that adjust for real world needs.
Enterprise code with layers of abstraction isnt best practice. It’s enterprise code.
I would imagine that's why they had "best practices" in quotes. Lots of enterprisey things get pushed as a "good practice" to improve reuse (of things that will never be reused) or extensibility (of things that will never be extended) or modularity (of things that will never be separated).
Enterprise development has particular problems you won't find in other environments, for instance having hundreds of different developers with widely varying levels of skill and talent, all collaborating together, often under immense time and budget pressure.
The result ain't going to be what you get if you've got a focused group of 10x geniuses working on everything, but I think a lot of the aspects of "enterprise development" that people complain about is simply the result of making the best of a bad situation.
I like Java, because I've worked with people who will fuck up repeatedly without static type checking.
> for instance having hundreds of different developers with widely varying levels of skill and talent
That's a management problem. Meaning you assess that risk and try to alleviate it. A good solution like you say is languages with good type checking support. Another is code familiarity and reuse through frameworks and libraries. A third may be enforcing writing tests to speed up code review (and checklist rules like that).
It's going to be boring, but boring is good at that scale.
I can attest to that and see it as the reason why Angular is still so popular in the enterprise world - it has such a strong convention that no matter the rate of staff rotation the team can keep delivering.
Meanwhile no two React projects are the same because they typically have several dependencies, each solving a small part of the problem at hand.
Mindless repetition of something you've internalized and never think about and never get any better at is "Best Reflex" not "Best Practice".
Nah, these are the people who don't know the difference between a variable and a function call and who think FizzBuzz is a "leetcode interview problem".
I hate it when variables won't and constants aren't and functions don't.
same, the amount of work I have to put into thinking of what to say to the llm is the same or more work than just telling the compiler or interpreter what I want (in a language I'm familiar with), and the actual coding is the trivial part. in fact I get instant feedback with the code, which helps change my thinking. with the llm, there's an awkward translating for the llm, getting the code, checking that it might do what I want, and then still having to run it and find the bugs.
the balance only shifts with a language/framework I'm not familiar with.
I think it’s useful to think of LLMs performing translation from natural language to a program language. If you already speak the programming language fluently, why do you need a translator?
> If you already speak the programming language fluently, why do you need a translator?
And if you don't speak the language please spare us from your LLM generated vibe coding nonsense
I agree for method-level changes, but the more you’re willing to cede control for larger changes, even in a familiar language, the more an LLM accelerates you.
For me, I give Gemini the full context of my repo, tell it the sweeping changes I want to make, and let it do the zero to one planning step. Then I modify (mostly prune) the output and let Cursor get to work.
And the article is overstating it as well. My confidence in the LLM's ability to reduce the "how" part is primarily based on "am I doing something the LLM is good at?". If I'm doing HTML React where there's a million examples of existing stuff, then great. The more novel what I'm asking is, the less useful the LLM becomes and the more stuff I need to handcode is. Just as with self-driving cars, this is a challenge because switching from "the LLM is generating the code" to "I'm hand-tweaking things" is equivalent to self-driving disconnecting randomly and telling you "you drive" in the middle of the highway. Oh and I've caught the LLM randomly inserting vulnerabilities for absolutely no reason (e.g. adding permissions to the iframe sandbox attribute when I complained about UI layout issues).
It's a useful tool that can accelerate certain tasks, but it has a lot of sharp edges.
> Oh and I've caught the LLM randomly inserting vulnerabilities for absolutely no reason (e.g. adding permissions to the iframe sandbox attribute when I complained about UI layout issues).
Yeah, now get the LLM to write C++ for a public facing service, what could possibly go wrong?
> If I'm doing HTML React where there's a million examples of existing stuff, then great
I do quite a bit of this and even here LLMs seem extremely hit and miss, leaning towards the miss side more often than not
I think React is one of those areas where consistency is more important than individual decisions. With a lot of front-end webdev there's many right answers, but they're only right if they are aligned with the other design decisions. If you've ever had to edit a web page with three different approaches to laying out the CSS you know what I mean.
LLMs _can_ do consistency, they're pretty good continuing a pattern...if they can see it. Which can be hard if it's scattered around the codebase.
> one of those areas where consistency is more important than individual decisions
This describes any codebase in any programming language
This is why "programming patterns" exist as a concept
The fact that LLMs are bad at this is a pretty big mark against them
Consistency is why frameworks and libraries exists. Once you start to see consistency in your UI views, that's a good sign to further refine it into components and eliminate boilerplate.
> LLMs _can_ do consistency
They won't even consistently provide the same answer to the same input. Occasional consistency is inconsistency.
My favorite is when I ask it to fix a bug, and in the part of the code that doesn't change it still slightly rewords a comment.
I think you're overly painting that process as a waterfall method. In reality, i think its more of a loop. You do the loop a bunch of times and the solution gets better and better. The act of coding sometimes exposes a lot more of the requirement questions you didn't even know to ask in the first few steps.
So anything that can let you iterate the loop faster is good. The analogy is kind of like if you can make your compile and tests faster, its way easier to code. Because you don't just code and test at the very end, you do it as part of a thinking loop.
You can get a lot of stuff designed before having to start the loop, just like you can get the boilerplate code written (or use a framework), before writing any business logic.
Writing code to find specs is brute-forcing the solution. Which is only useful when there's no answer or data (kinda rare in most domains). Taking some time to plan and do research can resolve a lot of inconsistency in your starting design. If you have written the code before, then you'll have to refactor even if the program is correct, because it will be a pain to maintain.
In painting, even sketching is a lot of work. Which is why artists will collect references instead, mentally select the part they will extract. Once you start sketching, the end goal is always a final painting, even if you stop and redo midway. Actual prototyping is called a study and it's a separate activity.
I agree, they are very much exaggerating both time spent writing code, as well as the amount of time LLMs shave off. LLM coding very much does NOT take “near zero time,” I would argue that sometimes it can take the same amount of time or longer, compared against simply knowing what you are doing, with tools you know how to use, referring to documentation you know how to interpret, understanding the systems around, the business around, what team A and C need in two quarters so we better keep it in mind… etc.
I had the weirdest experience the other day. I wanted to write an Expo React Native application - something I have zero experience with (I’ve been writing code non-stop since I was a kid, starting with 6502 assembly). I’ve leaned heavily on Sonnet 3.7 and off we went.
By the end of the day (10-ish hours) all I got to show was about 3 screens with few buttons each… Something a normal React developer probably would’ve spat out in about a hour. On top of that, I can’t remember shit about the application itself - and I can practically recite most of the codebases that I’ve spent time on.
And here I read about people casually generating and erasing 20k lines of code. I dunno, I guess I am either holding it wrong, or most of the time developing software isn’t spent vomiting code.
Interesting. I had the exact opposite experience recently.
I've also been writing code for a long time, did the 6502 assembly thing way back when, and lots since then. For this current project I wanted to build a web app with a frontend in Angular and a backend in Java 21 relying on javalin.io for the services layer. It had a few other integrations as well - into a remote service requiring OAuth and also into subtlecrypto. After less than 10 hours I had a fully functioning MVP that was far superior to anything I could have created without an assistant. It gave me build files, even a test skeleton. Restyling the UI or reflowing the UX to include confirmations, additional steps, modals, ... was really easy. I just had to type it, and those changes would get made. It felt like I was "director of development" for a day.
I used Aider, plugged into Gemini 2.5.
Well... In my case the scaffolding was done by the Expo template, used Expo libraries for social login and I wrote the Expo API backend functions.
Was it productivity boost for me - yeah, cause I know mostly shit about React. But as an end result it just felt very underwhelming. Discussing it today with my brother (who lives and breathes FE) it apparently was.
I guess I was just expecting... I dunno... more - people are claiming nX productivity boosts, and considering how the UI is mostly boilerplate...
Just to continue my train of thought, because I keep coming back to this.
I think I was expecting that it will turn me into a FE developer and it will feel as natural and smooth as usual when I am in my element.
It didn’t. And the results weren’t what you would get from a real FE dev. And it felt unsatisfactory, stressful and ultimately hollow.
I guess _for me_ it would be fine for a throw away MVP - something that I don’t want to put my heart into.
>That last part is actually the easiest
If it were, the median e.g. business analyst should be getting paid significantly more than the median software engineer. That's not what the data shows, however.
>I can genuinely say in all of my programming projects, I spent more time understanding the problem than writing code.
This is almost trivially true for anyone who understands the problem via writing code, though.
You're assuming only the last part is what software engineer do.
The business analyst mostly just scratch the top half of the first part.
But I do encourage them to go vibe coding! It's providing a lot of entertainment. On off chance, they would become one of us and would be most welcomed.
I'm not, but any time spent on #3 is time not spent on #1 and #2. So why wouldn't a profession specialized in the harder tasks make more money?
My real point is claiming #3 is the easiest is just silly. It's obviously much easier to come up with good business ideas in the abstract than to bring them into being. The mixture works because software as a business is an O-ring problem. These 3 tasks are not cleanly separable, they're all part of a feedback loop together.
> What do I need to do? Designing the solution conceptually
That's not respecting #2, which still fall squarely in engineering profession.
The design of the solution are necessarily technical, otherwise it's just throwing a bunch of concept and big words to sounds cool and leads to nowhere.
The outcome of this solution would then go back and influence #1 which is the behavior that customer see. If Steve Jobs couldn't fit all of his components into his iphone then it wouldn't have existed, and he might have to settle for something less, like an ipod.
Obviously this would all exist in a ring and that's why everyone is continuously employed and mostly not fired once the product gets released.
What is an O-ring problem?
> If it were, the median e.g. business analyst should be getting paid significantly more than the median software engineer.
What if you replace "business analyst" with "software architect"?
Or tech lead and senior engineer. Because they spend more time doing the first two than that last one.
I spend most of my time talking to stakeholders and BAs to help them better understand what their actual problem is instead of coming to me with "we want this" :/
Writing the code is the trivial part.
Writing code is the trivial part, yet it can be quite time consuming. I know what I want, so I don't want to care about the trivial minutae, same as I care very little what machine code falls out of my compiler. LLMs aren't capable yet to enable this easily and reliably, but they present a (often useful) glimpse.
"Business analyst" is not a real job and problem domain analysis is done by software engineers in 100 percent of the workplaces I know.
It's a real job - but more in IT and less software development. IT departments in many places prefer to do the buy rather than build since build is more expensive for them.
I'm somebody who used to think your way until very recently (long-time vim user, fast typer, etc.).
I'd recommend you give `aider` specifically a try. It's slowly taken over more and more of the "what" and "how" buckets outlined in the article, especially for large-surface-area code bases.
It turns out, for me at least, there is a big mental activation hurdle between "what" and "how". I need a lot of focus time to pivot between "what" and "how" efficiently, especially for work that spans large parts of the codebase, and work that I'm not super excited about doing. Using `aider` has lowered this activation threshold dramatically. It's made "writing code" about as simple as talking about a technical solution with an intelligent colleague.
I usually follow the format (1) describe the context of the app / problem you're trying to solve (2) describe what you know the solution will look like (3) ask it for clarifying questions / if it needs any examples or context to know the problem space better, and if the solution makes sense / do they see any issues with it? (4) ask it to outline the solution in greater detail, do not write code (5) add any clarifications, now do the thing.
i.e. it's kind of similar to interacting with a super fast, eager, indefatigable junior engineer. Sometimes it misses things or misunderstands, but not nearly enough to make the juice not worth the squeeze. These days, I'd say I spend more time reading/editing claude-generated code, writing commit messages, and managing deployments than I do writing code. It's a higher level of abstraction and I get way more leverage out of the deal. The code I'm writing is, on balance, better than the code I wrote before. It took maybe a few months to get here, but I'm happier for giving it a shot.
For many developers the first couple of items isn't a thing, we're just given requirements and the designs. At most, you can point out issues and do time estimates.
For my current job coding is 90% of my time. The rest is meetings, deployments, ticket management. Most of the time coding isn't particularly hard, but it sure consumes lots of time. I've had many days with 1000+ line diffs.
How common is this, really? I've never had a job like this, since about my first year or so at the entry level.
over 15 yrs of embedded dev here and 1/2 is 90% the problem every project
> With Claude, that time cost has plummeted to nearly zero.
not sure if anyone knows. how good would a bigquery-sql to scala parser generated code would be? can i use it without having to dig into generated code?
How do you understand the problem without writing any code?
It's possible that people's experiences are different to yours because you work on a specific type of software and other people work on other specific types of software.
By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is more concrete and can highlight mistakes like when there's a gap in your understanding vs spots where details matter more specifically.
At many big tech companies I've worked out, an abstract design proposal precedes any actual coding for many tasks. These design proposals are not about how you lay out code or name variables, but a high level description of the problem and the general approach to solve the problem.
Expressing that abstract thinking requires writing code but that's the "how" - you can write that same code many ways.
> By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is more concrete and can highlight mistakes like when there's a gap in your understanding vs spots where details matter more specifically.
The whole argument behind TDD is that it's easier to write code that verify something than actually implement the code. Because it only have the answer, not the algorithm to solve the question.
So for any code you will be writing, find the answers first (expected behavior). Then add tests. The you write the code for the algorithm to come up with the answer.
Static typing is just another form of these. You tell the checker: This is the shape of this data, and it warns you of any code that does not respect that.
And an even stronger approach than TDD would be to develop a formal proof in something like Coq. At some point you have to define your algorithm and it’s easier when you actually have some inkling of how it would work rather than just trying to blindly get a test suite to pass.
If you haven't solved exactly the same problem before, specifying a solution before writing code is a bad idea imo. More often than not, it turns out that the prematurely defined general approach isn't very optimal.
Which points at a pretty substantial limitation of LLM coding...
The solution is always out there. The code is just an automated way to get it without the error prone way of humans doing manual calculations. But sometimes, your understanding is flawed, so the code you write is not the correct way to have the solution. Which is why you have to get actual correct answers (specs) before writing code.
Correctness is not embedded in software. It's embedded in the real world.
Typically I find a novel problem domain requires roughly about 3 attempts from scratch to get a maintainable longer-term solution. However, that still requires having some idea in mind to try before just writing code. Of course you might also do some prototyping on certain subparts of the problem but there’s only so much of that that can be done and you’re still trying out what expressing high level ideas looks like / how it works.
I don’t think there’s anything where the first step is writing code. It’s like saying the first step of solving a math problem is writing down equations.
>How do you understand the problem without writing any code?
Not OP, but I find this a very good question. I've always found that playing with the problem in code is how I refined my understanding of the problem. Kind of like how Richard Feynman describes his problem solving. Only by tinkering with the hard problem do you really learn about it.
I always found it strange when people said they would plan out the whole thing in great detail and code later. That never worked for me, and I've also rarely seen it work for those proposing it.
It may be because I studied control systems, but I've always found you need the feedback from actually working with the problem to course correct, and it's faster, too. Don't be scared to touch some code. Play with it, find out where your mental model is deficient, find better abstractions than what you originally envisioned before wrestling with the actual problems.
It's not building the whole architecture before coding. It's about getting all the answers before spending time coding things that will probably have hidden bugs.
Sometimes you don't have a way to get the exact answers, so you do experiments to get data. But just like scientists in a lab, they should be rigorous and all assumptions noted down.
And sometimes, there are easy answers, so you can get these modules out of the way first.
And in other cases, maybe a rough solution is better than not having anything at all. So you implement something that solves a part of the problem while you're working on the tougher parts.
Writing code without answers is brute-forcing the solution. But novel problems are rare, so with a bit of research, it's quite easy to find answers.
>And in other cases, maybe a rough solution is better than not having anything at all.
POCs are better for customer-facing, product management driven work. This is because they can be bad at describing what they want. There's more risk of building the wrong thing.
POCs can be okay for system design or back-end work (or really anything not involving vague asks), but chances are planning and deeper thinking will help you more there because the problems you solve tend to be less subjective. Less risk of building the wrong thing.
Rough solution in this case is more like a sketch compared to a painting, a few hours of work instead a week or two. The painting can be the main goal, but a sketch can be useful for some part.
Kinda like scaling. Instead of going for Kubernetes, use a few VPS and a managed database to get your first customers.
I’ve grown weary of people repeating absolutisms they hear online, too.
As is usually the truth in practice, it’s a mess, which is why I’ve seen combinations of upfront planning and code spiking work the best.
An upfront plan ensures you can at least talk about it with words, and maybe you’ll find obvious flaws or great insights when you share your plan with others. Please, for the love of god, don’t ruin it with word vomit. Don’t clutter it with long descriptions of what a load balancer is. Get to the point. Be honest about weaknesses, defend strengths.
Because enterprise corporate code is a minefield of trash, you just have to suck it up and go figure out where the mines are. I’ve heard so many complaints “but this isn’t right! It’s bad code! How am I supposed to design around BAD code!” I’ll tell you how, you find the bad parts, and deal with them like a professional. It’s annoying and slow and awful, but it needs doing, and you know it.
By not doing the planning, you run the risk of building a whole thing, only to be told “well, this is nice, but you could have just done X in half the time.” By not doing the coding, you risk blowing up your timeline on some obvious unknown that could have been found in five minutes.
If I have any representation of the problem in front of me the mind seems to attack it all by it self. I strongly suspect someone with more (or different) experience doesn't need this or gets better results by writing out a representation.
This is true when breaking new ground, but it’s a rare occurrence. Most business problems are a few thousand years old. Yes, there were taxes paid in the ancient world.
They weren't solving hard realtime nonlinear control for hardware running on a custom ASIC in a domain only a literal handful of companies even operate in.
Not everything has been solved for ten thousand years.
You misread. Also, that tech has been around for decades.
> That last part is actually the easiest, and if you're spending inordinate amount of time there, that usually means the first two were not done well or you're not familiar with the tooling (language, library, IDE, test runner,...).
I'm not sure if you're familiar with modern JS frameworks.
I started my career as a developer in the 1990s and cut my teeth in C++, moving on to Python, Perl, Java, etc. in the early-2000s. Then I did management roles for about 20 years and was no longer working at the “coal face” despite having learned some solid software engineering discipline in my early days.
As an old geezer, I appreciate very much how LLMs enable me skip the steep part of the learning curve you have to scale to get into any unfamiliar language or framework. For instance, LLMs enabled me to get up to speed on using Pandas for data analysis. Pandas is very tough to get used to unless you emerged from the primordial swamp of data science along with it.
So much of programming is just learning a new API or framework. LLMs absolutely excel at helping you understand how to apply concept X to framework Y. And this is what makes them useful.
Each new LLM release makes things substantially better, which makes me substantially more productive, unearthing software engineering talent that was long ago buried in the accumulating dust pile of language and framework changes. To new devs, I highly encourage focusing on the big picture software engineering skills. Learn how to think about problems and what a good solution looks like. And use the LLM to help you achieve that focus.
I've been using it to learn Lean, the proof assistant language, and it's great. The code doesn't always compile, but the general structure and approach is usually correct, and it helps understand different ways of doing things and the pros, cons, and subtleties of each.
From this it has me wondering if AI could increase the adoption of provably correct code. Dependent types have a reputation for being hard to work with, but with AI help, it seems like they could be a lot more tractable. Moreover, it'd be beneficial it the other direction too: the more constraints you can build into the type system of your domain model, the harder it will be for an AI to hallucinate something that breaks it. Anything that doesn't satisfy the constraints will fail to compile.
I doubt it, but wishful thinking.
Yep, same. I'm an old hand at pandas, and writing a 300 line script in pandas and asking Claude to rewrite it to polars taught me polars faster than any other approach I've used to learn a new framework.
Yep, I absolutely relate to this. ChatGPT happened to come out right when I needed to learn how to use kubernetes, after having used a different container orchestrator. It made this so much easier.
Ever since, this has been my favorite use case, to cut through the accidental complexity when learning a new implementation of a familiar thing. This not only speeds up my learning process and projects using the new tool, it also gives me a lot more confidence in taking on projects with unfamiliar tools. This is extremely valuable.
> primordial swamp of data science
This deeply resonates with me every time I stare at pandas code seeking to understand it.
I am pretty much in the same boat, although I was never that advanced a dev to begin with.
It is truly amazing what a superpower these LLM tools are for me. This particular moment in time feels like a perfect fit for my knowledge level. I am building as many MVP ideas as quickly as I can. Hopefully, one of them sticks with users.
> So much of programming is just learning a new API or framework.
Once you're good at it in general. I recently witnessed what happens when a junior developer just uses AI for everything, and I found it worse than if a non-developer used AI: at least they wouldn't confuse the model with their half-understood ideas and wouldn't think they could "just write some glue code", break things in the process, and then confidently state they solved the problem by adding some jargon they've picked up.
It feels more like an excavator: useful in the right hands, dangerous in the wrong hands. (I'd say excavators are super useful and extremely dangerous, I think AI is not as extreme in either direction)
It used to (pre-'08 or so) be possible to be "good at Google".
Most people were not. Most tech people were not, even.
Using LLMs feels a ton like working with Google back then, to me. I would therefore expect most people to be pretty bad at it.
(it didn't stop being possible to be "good at Google" because Google Search improved and made everyone good at Google, incidentally—it's because they tuned it to make being "bad at Google" somewhat better, but eliminated much of the behavior that made it possible to be "good at Google" in the process)
This is an excellent analogy. I will be borrowing it. Thank you.
Fun fact, I recently started reading Designing LLM Applications[0] (which I'm very much enjoying by the way) and it draws this exact analogy in the intro!
0: https://www.oreilly.com/library/view/designing-large-languag...
I swear I didn't steal mine from there, LOL. Maybe I'm on the right track if others are noticing similar things about the experience of using LLMs, though.
Yes exactly, I meant it as evidence that there is something to this insight. Also that it stuck with me in the book enough to make the connection when I saw your comment; it's that it struck me as a good point.
Thank you, you just sold me on an O'Reilly free trial. Let's see what damaged I can do to that book in 10 days.
Also agree. I've been playing with Godot for some super simple game dev, and it's been surprisingly fantastic at helping me navigate Godot's systems (Nodes, how to structure a game, the Godot API) so I can get to the stuff that I find enjoyable (programming gameplay systems).
No, it's not perfect and I imagine there's some large warts as a result, but it was much, much better than following a bog-standard tutorial on YouTube to get something running, and I'm always able to go refactor my scripts later now that I'm past initial scaffolding and setup.
> The developers who thrive in this new environment won’t be those who fear or resist AI tools, but those who master them—who understand both their extraordinary potential and their very real limitations. They’ll recognise that the goal isn’t to remove humans from the equation but to enhance what humans can accomplish.
I feel like LLMs are just the next step on the Jobs analogy of "computers are bicycles for the mind" [0]. And if these tools are powerful bicycles available to everyone, what happens competitively? It reminds me of a Substack post I read recently:
> If everyone has AI, then competitively no one has AI, because that means you are what drives the differences. What happens if you and LeBron start juicing? Do you both get as strong? Can you inject your way to Steph’s jumpshot? What’s the differentiator? This answer is inescapable in any contested domain. The unconventionally gifted will always be ascendant, and any device that’s available to everyone manifests in pronounced power laws in their favor. The strong get stronger. The fast get faster. Disproportionately so. [1]
[0] https://youtu.be/ob_GX50Za6c?t=25
[1] https://thedosagemakesitso.substack.com/p/trashbags-of-facts...
If you and Lebron both had mech-suits you'd be equal in strength. Actually you might find that maybe you communicate better with the machine as you've had to communicate a lot more for work and have further refined those neural patterns. So actually, I would expect those with exceptional communication skills and creativity to be the best able to take advantage of AI. In a world where functional code in any language can be spat out at 1000 tokens/s, it matters a lot more that you can communicate your vision than understanding the inscrutable byte-level architecture of ARM-64 or how to write a CUDA kernal, or how to use a static class properly.
LeBron James still knows more about how to play basketball than whoever is in the mech suit opposite him.
I don't think bicycle analogy is adequate. It seems that they are more like cars. And if we follow that analogy, it suggests that the direction of the evolution will depend on whether we make our society dependent on being able to drive cars and grow fat from lack of activity or use them in a more mindful 'for purpose intended' way.
Simon Willison nailed exactly this 2 years ago:
> I've been thinking about generative AI tools as "bicycles for the mind" (to borrow an old Steve Jobs line), but I think "electric bicycles for the mind" might be more appropriate.
> They can accelerate your natural abilities, you have to learn how to use them, they can give you a significant boost that some people might feel is a bit of a cheat, and they're also quite dangerous if you're not careful with them!
https://simonwillison.net/2023/Feb/13/ebikes/
https://packet.boutique/technohumanism/codex/index.html
Technology is part of humanity. Just as a hammer extends the hand, so too does the LLM extend the mind.
> Experience Still Matters
My personal opinion is that now experience matters a lot more.
A lot of times, the subtle mistakes that LLM makes or wrong direction that it takes can only be corrected by experience. LLM also don't tend to question its own decisions in the past, and will stick with them unless explicitly told.
This means LLM based project accumulate subtle bugs unless there is a human in the loop who can rip them out, and once a project accumulated enough subtle bugs it generally becomes unrecoverable spaghetti.
> LLM also don't tend to question its own decisions in the past, and will stick with them unless explicitly told.
Dangerous as well, is that LLMs won't (unless aggressively prompted to) question your own decisions either, in contrast to something like a mentor which would help you discover a better way, if there is one.
That part didn't change with or without LLMs though. At least LLM is one more set of eye on my own decisions.
I've never seen anyone claim that coding LLMs are mentors, but rather junior devs there to help you. Taking them as mentors changes the task completely. LLM-as-junior-dev definitely requires you to know what you want the code to do and what you expect as quality output.
A lot of good points here which I agree with.
Another way to think about it is SWE agents. About a year ago Devin was billed as a dev replacement, with the now common reaction that it's over for SWEs and it's no longer a useful to learn software engineering.
A year later there have been large amounts of layoffs that impacted sw devs. There have also been a lot of fluff statements attributing layoffs to increased efficiency as a result of AI adoption. But is there a link? I have my doubts and think it's more related to interest rates and the business cycle.
I've also yet to see any AI solutions that negate the need for developers. Only promises from CEOs and investors. However, I have seen how powerful it can be in the hands of people that know how to leverage it.
I guess time will tell. In my experience the current trajectory is LLMs making tasks easier and more efficient for people.
And hypefluencers, investors, CEOs, and others will continue promising that just around the corner is a future in which human software developers are obsolete.
ceos found AI as escape hatch for their over hiring during pandemic boom year.
they were just playing to this market reaction
layoffs = bad
layoffs because of AI = good
Yup. Also I am excited for the bump in my rates when the cycle inverts and there's a dearth of people who can code without the then defunct LLMs.
Keep believing it is augmentation.
The end game is outsourcing, instead of team mates doing the actual programing from the other side of the planet, it will be from inside the computer.
Sure the LLMs and Agents are rather limited today, just like optimizating compilers were still a far dream in the 1960's.
That's kinda obvious that's their goal especially with the current focus on coding of most of the AI labs in most announcements - it may be augmentation now but that isn't the end game. Everything else these AI labs do, while fun seems like at most a "meme" to most people in relative terms.
Most Copilot style setup's (not just in this domain) are designed to gather data and train/gather feedback before full automation or downsizing. If they outright said it they may not have got the initial usage needed to do so from developers. Even if it is augmentation it feels like at least to me the other IT roles (e.g. BA's, Solution Engineers maybe?) are safer than SWE's going forward. Maybe its because dev's have a skin in the game and without AI its not that easy of a job over time makes it harder for them to see. Respect for SWE as a job in general has fallen in at least my anecdotal conversations mainly due to AI - after all long term career prospects are a major factor in career value, social status and personal goals for most people.
Their end goal is to democratize/commoditize programming with AI as low hanging fruit which by definition reduces its value per unit of output. The fact that there is so much discussion on this IMO shows that many even if they don't want to admit it there is a decent chance that they will succeed at this goal.
And just like optimizing compilers LLMs also emit code that is difficult to verify and no-one really understands, so when the shit hits the fan you have no idea what's going on.
Is it though? Most code that LLM emits are easier to understand than equivalent code by humans in my experience, helped by overt amount of comment added at every single step.
That's not to say the output is correct, there are usually bugs and unnecessary stuff if the logic generated isn't trivial, but reading it isn't the biggest hurdle.
I think you are referring to the situation where people just don't read the code generated at all.. in that case it's not really LLM's fault.
> Most code that LLM emits are easier to understand than equivalent code by humans in my experience
Even if this were true, which I strongly disagree with, it actually doesn't matter if the code is easier to understand
> I think you are referring to the situation where people just don't read the code generated at all.. in that case it's not really LLM's fault
It may not be the LLM's "fault", but the LLM has enabled this behavior and therefore the LLM is the root cause of the problem
I agree that AI powered programming can give you a boost, and the points made in the post I would agree with if they were not made about Claude Code or other "agentic" coding tools. The human-LLM boosting interaction exists particularly when you use the LLM in its chat form, where you inspect and reshape with both editing the code and explaining with words what the LLM produced, and where (this is my golden rule) you can only move code from the LLM environment to your environment after inspecting and manually cut & pasting stuff. Claude Code and other similar systems have a different goal: to allow somebody to create a project without much coding at all, and the direction is to mostly observe more the result itself of the code, that how it is written and the design decisions. This is fine with me, I don't tell people what to do, and many people can't code, and with systems like that they can build a certain degree of systems. But: I believe that tody, 21 April 2025 (tomorrow it may change) the human+LLM strict collaboration on the code, where the LLM is mostly a tool, is what produces the best results possible, assuming the human is a good coder.
So I would say there are three categories of programmers:
1. Programmers that just want to prompt, using AI agents to write the code.
2. Programmers, like me, that use LLM as tools, writing code by hand, letting the LLM write some code too, inspecting it, incorporating what makes sense, using the LLM to explore the frontier of programming and math topics that are relevant to the task at hand, to write better code.
3. Programmers that refuse to use AI.
I believe that today category "2" is what has a real advantage over the other two.
If you are interested in this perspective, a longer form of this comment is contained in this video in my YouTube channel. Enable the English subtitles if you can't understand Italian.
https://www.youtube.com/watch?v=N5pX2T72-hM
This is my experience as well. I've been skeptical for a long time, but recent releases have changed my mind (it's important to try new things even if skeptical). Large context windows are game-changers. I can't copy/paste fast enough.
The future is coming, but you still need fundamentals to make sure the generated code has been properly setup for growth. That means you need to know what you expect your codebase to look like before or during your prompting so you can promote the right design patterns and direct the generation towards the proper architecture.
So software design is not going away. Or it shouldn't for software that expects to grow.
I've also settled on a copy-paste LLM workflow.
I can see the usefulness of agents however for (a) some tedious refactorings where the IDE features might not reach and (b) occasionally writing a first pass of a low-value module when I am low on energy.
For the rest of stuff I feel very happy with copy-paste.
2. is mostly what works for me.
Usually when I am in the flow of writing code, I can think, write, tab away and review without breaking it. If I need a smallish (up to 100-ish lines) piece of code that I know the shape of - I would use the chat to generate it and merge it back after review.
Letting the agent rip always has led to more pain and suffering down the line :(
> The human-LLM boosting interaction exists particularly when you use the LLM in its chat form
I feel reassured to see that I'm not the only one who feels this way. With all the talk about in-IDE direct code editing, I was thinking that I was being somewhat of a luddite who feels like the chat form is the best balance between getting help from the AI and understanding/deciding how things are actually structured/working.
This may depend upon every individual, but for me "How am I going to do it" is not actually writing code. It's about knowing how I'm going to do it before I write the code. After that point, its an exercise in typing speed.
If I'm not 100% sure something will work, then I'll still just code it. If it doesn't work, I can throw it away and update my mental model and set out on a new typing adventure.
And the only way to be 100% sure is to have written exactly the same thing before, which makes zero sense.
That's not true. I just wrote a similar comment about design coming first. If you've written software for awhile you just know what it looks like and which design patterns will be useful. Then when you see what your LLM says is the right code you can glance at it and see if it is even on the right track.
If you're trying to LLM your way to a new social site you're going to need to know what entities make up that site and the relationships they have ahead of time. If you have no concept of an idea then of course the LLM will be "correct" because there were no requirements!
Software design is important today and will be even more important in the future. Many companies do not require design docs for changes and I think it is a misstep. Software design is a skill that needs to be maintained.
Archive.org link (site is down, for me.) https://web.archive.org/web/20250421152532/https://matthewsi...
Expectation: mech suit with developer inside.
Reality: a saddle on the developer's back.
They really want a faster horse.
https://web.archive.org/web/20250421182808/https://matthewsi... Site got hugged
I question how much code and what kind of code is actually going to be needed when the world is composed entirely of junior engineers who can write 100 LOC a second?
Will it just be these functional cores that are the product, and users will just use an LLM to mediate all interaction with it? The most complex stuff, the actual product, will be written by those skilled in mech suits, but what will it look like when it is written for a world where everyone else has a mech suit (albeit less capable) on too?
Think like your mother running a headless linux install with an LLM layer on top, and it being the least frustrating and most enjoyable computing experience she has ever had. I'm sure some are already thinking like this, and really it represents a massive paradigm shift in how software is written on the whole (and will ironically resemble the early days of programming).
I doubt it will come to that. Most interactions are always going to be much easier with a dedicated UI than with a chatbot. In fact, I can't think of anything I use regularly that I'd rather replace the UI with chat.
The UI will be a thin, flexible facade over a chatbot.
If we go with this analogy, we don't have advanced mech suits yet for this. To think an IDE is going to be the "visor", and to think copy-and-pasting is going to be jury-rigged weapons on the Mech is probably not it. The future really needs to be Jarvis and that Iron Man suit, whatever the programming equivalent is.
"Hey I need a quick UI for a storefront", can be done with voice. I got pretty far with just doing this, but given my experience I don't feel fully comfortable in building the mech-suit yet because I still want to do things by hand. Think about how wonky you would feel inside of a Mech, trying to acclimate your mind to the reality that your hand movements are in unity with the mech's arm movements. Going to need a leap of faith here to trust the Mech. We've already started attacking the future by mocking it as "vibe coding". Calling it a "Mech" is so much more inspiring, and probably the truth. If I say it, I should see it. Complete instant feedback, like pen to paper.
> We've already started attacking the future by mocking it as "vibe coding".
The term ‘vibe coding’ was coined by OpenAI’s co-founder.
https://x.com/karpathy/status/1886192184808149383
Copy/paste coding isn't exactly a new idea, it just got a lot easier and more popular.
> How LLM-powered programming tools amplify developer capabilities rather than replace them
This is my experience as well. You have to know what you want, how to interfere if things go in the wrong direction, and what to do with the result as well.
What I did years ago with a team of 3-5 developers I can do now alone using Claude Code or Cursor. But I need to write a PRD, break it down into features, epics and user stories, let the llm write code, review the results. Vibe coding tools feel like half a dozen junior to mid level developers for a fraction of the cost.
Yep. It’s the ultimate one person team. With the human playing the role of a team lead AND manager. Sometimes even the PM. You want to earn big bucks? Well, this is the way now. Or earn little bucks and lead a small but content life. Choice is yours.
The article is correct about the current state of using LLMs, but I didn't see an explanation WHY they are like this; just more "how".
I'm curious about the fundamental reason why LLMs and their agents struggle with executive function over time.
Theoretical limitations of multi-layer Transformer https://arxiv.org/abs/2412.02975
On Limitations of the Transformer Architecture https://arxiv.org/abs/2402.08164
Limits of Deep Learning: Sequence Modeling through the Lens of Complexity Theory https://arxiv.org/abs/2405.16674
TL;DR transformers are inherently limited with tasks requiring composition of sequential steps
In the current state of things, it's maybe more of a Justin Hammer mech suit than a Tony Stark mech suit.
How many people still play centaur chess?
sounds great as long as you don’t make any product or service that competes with Claude. Can anyone name something in that category?
guessing the introduction of the mech suit reduced headcount on the loading deck ...
More a halloween costume than mech suit.
Like a toy policeman costume so you can pretend you have authority and you know what you're doing.
> Chess provides a useful parallel here. “Centaur chess” pairs humans with AI chess engines, creating teams that outperform both solo humans and solo AI systems playing on their own. What’s fascinating is that even when AI chess engines can easily defeat grandmasters, the human-AI combination still produces superior results to the AI alone. The human provides strategic direction and creative problem-solving; the machine offers computational power and tactical precision.
Can we stop saying this? It hasn't been true for more than 15 years.