The 70% problem: Hard truths about AI-assisted coding

A field guide and why we need to rethink our expectations

Addy Osmani's avatar

Addy Osmani

Dec 05, 2024

1,413

68

218

Share

After spending the last few years embedded in AI-assisted development, I've noticed a fascinating pattern. While engineers report being dramatically more productive with AI, the actual software we use daily doesn’t seem like it’s getting noticeably better. What's going on here?

I think I know why, and the answer reveals some fundamental truths about software development that we need to reckon with. Let me share what I've learned.

How developers are actually using AI

I've observed two distinct patterns in how teams are leveraging AI for development. Let's call them the "bootstrappers" and the "iterators." Both are helping engineers (and even non-technical users) reduce the gap from idea to execution (or MVP).

The Bootstrappers: Zero to MVP

Tools like Bolt, v0, and screenshot-to-code AI are revolutionizing how we bootstrap new projects. These teams typically:

- Start with a design or rough concept

- Use AI to generate a complete initial codebase

- Get a working prototype in hours or days instead of weeks

- Focus on rapid validation and iteration

The results can be impressive. I recently watched a solo developer use Bolt to turn a Figma design into a working web app in next to no time. It wasn't production-ready, but it was good enough to get very initial user feedback.

The Iterators: daily development

The second camp uses tools like Cursor, Cline, Copilot, and WindSurf for their daily development workflow. This is less flashy but potentially more transformative. These developers are:

- Using AI for code completion and suggestions

- Leveraging AI for complex refactoring tasks

- Generating tests and documentation

- Using AI as a "pair programmer" for problem-solving

But here's the catch: while both approaches can dramatically accelerate development, they come with hidden costs that aren't immediately obvious.

The hidden cost of "AI Speed"

When you watch a senior engineer work with AI tools like Cursor or Copilot, it looks like magic. They can scaffold entire features in minutes, complete with tests and documentation. But watch carefully, and you'll notice something crucial: They're not just accepting what the AI suggests. They're constantly:

- Refactoring the generated code into smaller, focused modules

- Adding edge case handling the AI missed

- Strengthening type definitions and interfaces

- Questioning architectural decisions

- Adding comprehensive error handling

In other words, they're applying years of hard-won engineering wisdom to shape and constrain the AI's output. The AI is accelerating their implementation, but their expertise is what keeps the code maintainable.

Junior engineers often miss these crucial steps. They accept the AI's output more readily, leading to what I call "house of cards code" – it looks complete but collapses under real-world pressure.

The knowledge paradox

Here's the most counterintuitive thing I've discovered: AI tools help experienced developers more than beginners. This seems backward – shouldn't AI democratize coding?

The reality is that AI is like having a very eager junior developer on your team. They can write code quickly, but they need constant supervision and correction. The more you know, the better you can guide them.

This creates what I call the "knowledge paradox":

- Seniors use AI to accelerate what they already know how to do

- Juniors try to use AI to learn what to do

- The results differ dramatically

I've watched senior engineers use AI to:

- Rapidly prototype ideas they already understand

- Generate basic implementations they can then refine

- Explore alternative approaches to known problems

- Automate routine coding tasks

Meanwhile, juniors often:

- Accept incorrect or outdated solutions

- Miss critical security and performance considerations

- Struggle to debug AI-generated code

- Build fragile systems they don't fully understand

The 70% problem: AI's learning curve paradox

A tweet that recently caught my eye perfectly captures what I've been observing in the field: Non-engineers using AI for coding find themselves hitting a frustrating wall. They can get 70% of the way there surprisingly quickly, but that final 30% becomes an exercise in diminishing returns.

This "70% problem" reveals something crucial about the current state of AI-assisted development. The initial progress feels magical - you can describe what you want, and AI tools like v0 or Bolt will generate a working prototype that looks impressive. But then reality sets in.

The two steps back pattern

What typically happens next follows a predictable pattern:

- You try to fix a small bug

- The AI suggests a change that seems reasonable

- This fix breaks something else

- You ask AI to fix the new issue

- This creates two more problems

- Rinse and repeat

This cycle is particularly painful for non-engineers because they lack the mental models to understand what's actually going wrong. When an experienced developer encounters a bug, they can reason about potential causes and solutions based on years of pattern recognition. Without this background, you're essentially playing whack-a-mole with code you don't fully understand.

The learning paradox continued

There's a deeper issue here: The very thing that makes AI coding tools accessible to non-engineers - their ability to handle complexity on your behalf - can actually impede learning. When code just "appears" without you understanding the underlying principles:

- You don't develop debugging skills

- You miss learning fundamental patterns

- You can't reason about architectural decisions

- You struggle to maintain and evolve the code

This creates a dependency where you need to keep going back to AI to fix issues, rather than developing the expertise to handle them yourself.

The knowledge gap

The most successful non-engineers I've seen using AI coding tools take a hybrid approach:

1. Use AI for rapid prototyping

2. Take time to understand how the generated code works

3. Learn basic programming concepts alongside AI usage

4. Build up a foundation of knowledge gradually

5. Use AI as a learning tool, not just a code generator

But this requires patience and dedication - exactly the opposite of what many people hope to achieve by using AI tools in the first place.

Implications for the future

This "70% problem" suggests that current AI coding tools are best viewed as:

- Prototyping accelerators for experienced developers

- Learning aids for those committed to understanding development

- MVP generators for validating ideas quickly

But they're not yet the coding democratization solution many hoped for. The final 30% - the part that makes software production-ready, maintainable, and robust - still requires real engineering knowledge.

The good news? This gap will likely narrow as tools improve. But for now, the most pragmatic approach is to use AI to accelerate learning, not replace it entirely.

What actually works: practical patterns

After observing dozens of teams, here's what I've seen work consistently:

1. The "AI first draft" pattern

- Let AI generate a basic implementation

- Manually review and refactor for modularity

- Add comprehensive error handling

- Write thorough tests

- Document key decisions

2. The "Constant conversation" pattern

- Start new AI chats for each distinct task

- Keep context focused and minimal

- Review and commit changes frequently

- Maintain tight feedback loops

3. The "Trust but verify" pattern

- Use AI for initial code generation

- Manual review of all critical paths

- Automated testing of edge cases

- Regular security audits

Looking forward: The real promise of AI?

Despite these challenges, I'm optimistic about AI's role in software development. The key is understanding what it's really good for:

1. Accelerating the known

AI excels at helping us implement patterns we already understand. It's like having an infinitely patient pair programmer who can type really fast.

2. Exploring the possible

AI is great for quickly prototyping ideas and exploring different approaches. It's like having a sandbox where we can rapidly test concepts.

3. Automating the routine

AI dramatically reduces the time spent on boilerplate and routine coding tasks, letting us focus on the interesting problems.

What does this mean for you?

If you're just starting with AI-assisted development, here's my advice:

1. Start small

- Use AI for isolated, well-defined tasks

- Review every line of generated code

- Build up to larger features gradually

2. Stay modular

- Break everything into small, focused files

- Maintain clear interfaces between components

- Document your module boundaries

3. Trust your experience

- Use AI to accelerate, not replace, your judgment

- Question generated code that feels wrong

- Maintain your engineering standards

The rise of agentic software engineering

The landscape of AI-assisted development is shifting dramatically as we head into 2025. While the current tools have already changed how we prototype and iterate, I believe we're on the cusp of an even more significant transformation: the rise of agentic software engineering.

What do I mean by "agentic"? Instead of just responding to prompts, these systems can plan, execute, and iterate on solutions with increasing autonomy.

If you’re interested in learning more about agents, including my take on Cursor/Cline/v0/Bolt, you may be interested in my recent JSNation talk above.

We're already seeing early signs of this evolution:

From responders to collaborators

Current tools mostly wait for our commands. But look at newer features like Anthropic's computer use in Claude, or Cline's ability to automatically launch browsers and run tests. These aren't just glorified autocomplete - they're actually understanding tasks and taking initiative to solve problems.

Think about debugging: Instead of just suggesting fixes, these agents can:

- Proactively identify potential issues

- Launch and run test suites

- Inspect UI elements and capture screenshots

- Propose and implement fixes

- Validate the solutions work (this could be a big deal)

The Multimodal future

The next generation of tools may do more than just work with code - they could seamlessly integrate:

- Visual understanding (UI screenshots, mockups, diagrams)

- Verbal language conversations

- Environment interaction (browsers, terminals, APIs)

This multimodal capability means they can understand and work with software the way humans do - holistically, not just at the code level.

Autonomous but guided

The key insight I've gained from working with these tools is that the future isn't about AI replacing developers - it's about AI becoming an increasingly capable collaborator that can take initiative while still respecting human guidance and expertise.

The most effective teams in 2025 may be those that learn to:

- Set clear boundaries and guidelines for their AI agents

- Establish strong architectural patterns that agents can work within

- Create effective feedback loops between human and AI capabilities

- Maintain human oversight while leveraging AI autonomy

The English-first development environment

As Andrej Karpathy noted:

"English is becoming the hottest new programming language."

This is a fundamental shift in how we'll interact with development tools. The ability to think clearly and communicate precisely in natural language is becoming as important as traditional coding skills.

This shift towards agentic development will require us to evolve our skills:

- Stronger system design and architectural thinking

- Better requirement specification and communication

- More focus on quality assurance and validation

- Enhanced collaboration between human and AI capabilities

The return of software as craft?

While AI has made it easier than ever to build software quickly, we're at risk of losing something crucial - the art of creating truly polished, consumer-quality experiences.

The Demo-quality trap

It's becoming a pattern: Teams use AI to rapidly build impressive demos. The happy path works beautifully. Investors and social networks are wowed. But when real users start clicking around? That's when things fall apart.

I've seen this firsthand:

- Error messages that make no sense to normal users

- Edge cases that crash the application

- Confusing UI states that never got cleaned up

- Accessibility completely overlooked

- Performance issues on slower devices

These aren't just P2 bugs - they're the difference between software people tolerate and software people love.

The lost art of polish

Creating truly self-serve software - the kind where users never need to contact support - requires a different mindset:

- Obsessing over error messages

- Testing on slow connections

- Handling every edge case gracefully

- Making features discoverable

- Testing with real, often non-technical users

This kind of attention to detail (perhaps) can't be AI-generated. It comes from empathy, experience, and caring deeply about craft.

The renaissance of personal software

I believe we're going to see a renaissance of personal software development. As the market gets flooded with AI-generated MVPs, the products that will stand out are those built by developers who:

- Take pride in their craft

- Care about the little details

- Focus on the full user experience

- Build for the edge cases

- Create truly self-serve experiences

The irony? AI tools might actually enable this renaissance. By handling the routine coding tasks, they free up developers to focus on what matters most - creating software that truly serves and delights users.

The bottom line

AI isn't making our software dramatically better because software quality was (perhaps) never primarily limited by coding speed. The hard parts of software development – understanding requirements, designing maintainable systems, handling edge cases, ensuring security and performance – still require human judgment.

What AI does do is let us iterate and experiment faster, potentially leading to better solutions through more rapid exploration. But only if we maintain our engineering discipline and use AI as a tool, not a replacement for good software practices. Remember: The goal isn't to write more code faster. It's to build better software. Used wisely, AI can help us do that. But it's still up to us to know what "better" means and how to achieve it.

What's your experience been with AI-assisted development? I'd love to hear your stories and insights in the comments.

Subscribe to Elevat

The 70% problem: Hard truths about…

Addy Osmani

1,413

68

218

A field guide and why we need to rethink our expectations

Read →

68 Comments

Top first

User's avatar

Hackerman247's avatar

Hackerman247

Dec 6

Liked by Addy Osmani

Bookmarking this for future reference. It’s a great article and should be a must-read for all developers

Like (25)

Reply

Share

Jarad DeLorenzo's avatar

Jarad DeLorenzo

Dec 7

Liked by Addy Osmani

This entire article is a thousand percent accurate. And it reinforces my more recent finding that developers are fine. Contrary to most people's belief developers are probably amongst the most safe of any profession STILL. You hit on most of the reasons why but to take it even further, now with our abstraction level bumped up to natural language developers are unbound by their domain and can freely move back and forth across an unlimited landscape of possibilities - none with the rigorous formality of iterative process and our ability to assess the moving target of emerging tech picking out the winners and the duds and building the scaffolding for the next wave of emerging tech. This is only something learned through experience and no amount of textbooks or YouTube tutorials can make up for the hard time and dozens of mistakes made along the way. The future is bright for developers

Like (19)

Reply

Share

Lukas's avatar

Lukas

Dec 6

I almost never let LLMs write code for me, apart from simple repetitive auto-completion. Instead, I use it as a peer programmer, and ask it things like "what are common APIs to do X", or "how do I do X." Then I write the code myself with the help of the information it provides.

In my experience, this is faster than letting it write code and then refactoring it, and it avoids the problem where I accidentally overlook an issue in its code that I would not have created had I written the code myself. It also makes my code more consistent, since it's all written in my style, by my hand.

Like (11)

Reply (1)

Share

Brian Grubba's avatar

Brian Grubba

Jan 8

This seems like a reasonable way to use AI programming tools. Starting from 0 and trying to get an AI to develop the bulk of my code has always led to bizarrely complex code that doesn’t even follow the documentation for the relevant code or API.

Like (2)

Reply

Share

Alexis Gallagher's avatar

Alexis Gallagher

Dec 15

Liked by Addy Osmani

This piece is excellent, and matches a lot of my experience using various AI tools, and handling office hours in a course which is all about teaching people how to do problem solving with AI.

However, I’d say the “AI is like an eager junior coder” is somewhat misleading because it’s like a junior coder who has memorized the internet, and has the knowledge of a junior coder in more technical domains simultaneously than any senior coder.

This makes AI valuable in ways which have no close analogy, in addition to the ways which do.

Like (6)

Reply

Share

Dawid Makowski's avatar

Dawid Makowski

Dec 14

Liked by Addy Osmani

Agree 100%, good read.

I wrote an article with similar observation lately :)

https://dawidmakowski.com/en/2024/08/can-ai-code-sure-replace-us-nah/

Like (5)

Reply

Share

Misel's avatar

Misel

Dec 6

Liked by Addy Osmani

Thank you for writing this article, Addy. As a total programming noob I've been struggling to get anything "meaningful" after initial first round of prompting, and that's exactly why I got myself into learning Python from the scratch (so I can at least read the code). Your article is very important to keep me, and others, firmly grounded as well as to reminds us all that "Rome wasn't built in a day".

Like (4)

Reply (1)

Share

Byron Wright's avatar

Byron Wright

Jan 1

Be sure to get the LLM to explain the steps and decisions it makes when asking for help. As the article states, it is still a great learning tool. Even with tons of experience, I use an LLM to ramp up quickly if I'm digging into something unfamiliar.

Like (3)

Reply

Share

John Stewart's avatar

John Stewart

Dec 6

Liked by Addy Osmani

This is so good! Highlights many of the ways I use AI. Many of which I didn't even realize I was doing until you wrote it. As an example, I do create many different chats to isolate the context because if I don't the model gets confused more with what I'm asking. So many good bits in here. I also prefer your version of the future of AI and software development versus the one I cook up in my AI doomer brain sometimes 😄. Thanks for this!

Like (4)

Reply

Share

Oscar Nogueira Neto's avatar

Oscar Nogueira Neto

Dec 10

Liked by Addy Osmani

Congrats on the article! It summarizes the entire scene of AI and how this can be frustrating for developers, managers and executives!

Like (2)

Reply

Share

Csongor's avatar

Csongor

Dec 6Edited

Liked by Addy Osmani

Very well written, it fully resonates with me :)

What I can add here, is that productivity and quality can be combined into a method, framework, toolchain ... not necessarily requiring AI.

The idea is to produce, wherever possible, mathematical models throughout the software development life cycle / process (SDLC), and generate code from these models.

I've applied this idea into the React apps niche.

For example, the first step in the React app SDLC, the understanding of the problem can produce models using category theory and finite state machines. These models are turned automatically into React component architecture + State management code.

Of course there is need for manual coding, like filling the gaps with functions, where AI might help.

But the main idea stays the same: It is possible to generate likely-correct apps (the highest quality achievable without a sky-high budget), with new kind of formal methods (diagrams as code) which require small amount of coding.

Like (2)

Reply

Share

Alex's avatar

Alex

Apr 6

Liked by Addy Osmani

Spot on! One thing I’ve noticed is that Claude tends to write really long code that accounts for most possibilities and adds more features, while ChatGPT often has more efficient code but with fewer features.

Definitely agree that AI should be used more to speed up what you can do, rather than to simply do things for you.

Like (1)

Reply

Share

Matt AI's avatar

Matt AI

Mar 15

Liked by Addy Osmani

Really interesting point of view, and quite relatable. Thanks for sharing! What I found really helps is working from a todo file inside of cursor and indeed documenting key decisions and design choices in a memory.txt inside my root directory.

Like (1)

Reply

Share

Richard's avatar

Richard

Dec 12

If normal AI can write code that is 70% there but 30% a shitshow, why exactly are we expecting AI agents to do better? That they can they get stuck in a one step forward two steps back loop all on their own? I don't get it

Like (5)

Reply (3)

Share

Brian Grubba's avatar

Brian Grubba

Jan 8

Yes, people who say AI is incredible and is going to replace people in X years are crazy, and so are people who say AI is completely useless and the industry is dying. The truth, as always, is in between.

For example, I don’t see myself performing a Google search ever again in my life now that I have GPT and Gemini.

Like (2)

Reply

Share

Trevor Spencer's avatar

Trevor Spencer

Feb 22

The normal ai is still getting significantly better at each jump. Also humans write a lot of shit code lol

Like

Reply

Share

Erald David's avatar

Erald David

Jan 23

I also shared this view and while I think Addy really great job for writing this article, I felt like he unintentionally miss this big hole.

The reason that many people isn't so bullish on AI agents are precisely the same reasons that Addy mentioned above: it miss critical context and loop that need human to supervised. Although he mentioned the need of "Create an architecture that enable AI agents to safely code", it's still hard to see how this can solve these problems.

Like

Reply

Share

Eduards Normaals's avatar

Eduards Normaals

Dec 29

As a self-taught programmer who writes and learns code to automate my business processes, I love how AI enables me to focus less on syntax issues and more on the overall design and logic of my software. Previously, I would often get stuck on a few lines of code and spend hours experimenting to figure out what would happen if I tweaked or changed something. Alternatively, I’d take an online course, hoping it would address my specific problem.

Now, with AI, I can ask for detailed explanations of every line of code and get unstuck much faster. I still take online courses, but they’re now more focused on design and overall architecture. I also enjoy discussing potential design patterns with AI, exploring their drawbacks and benefits, and refining my codebase accordingly.

So far, my favorite tool is Cursor.

Like (4)

Reply

Share

Guidothekp's avatar

Guidothekp

Dec 18

Lost in all of this is the art of bootstrapping. That rough draft that AI wrote for you? That was where you'd have learnt what it takes to wade through verbiage and decide if something is relevant for you. You would have learnt how to string together pieces of seeming irrelevant code to make it work for the task at hand. You would have understood that it takes patience, understanding, and mental strength especially when the answer is not served on a platter. At the least you would have understood the reasoning behind the design.

What's the big deal, you say? After all, this is done for a few times. So why fret about it? All is hunky dory if we promise not to do this all the time, right?

To understand why some things are done differently on a code that used to work before, one has to understand what is going on under the covers. And this understanding has to be active. Active learning will let you see what is coming down the pike.

Did we talk about building confidence of being able to write code from the ground up instead of just copying a working piece?

Once you use an LLM to write code, you have smoked your first joint. You are now on the way to become an addict even if you are cognizant of it.

Like (4)

Reply

Share

Kevin's avatar

Kevin

Dec 6

AI is often good at writing code. But it's rarely good at debugging. It's not even really set up correctly to debug. It doesn't have the right inputs to observe what's going wrong, and it doesn't have the authority to use trial and error to fix bugs. It can't answer questions well about a medium size codebase that it wasn't trained on.

Hopefully all of these things improve in time. Personally, I would rather have an AI that was a great debugger and poor writer, than an AI that was a great code writer and poor debugger. For now I'll take what I can get ;-)

Like (3)

Reply

Share

Jari's avatar

Jari

Jan 6

I think another potential use case for AI is scaling software development team: I mean scaling in terms of completing simple tasks which no one has time to do, which could mean writing more tests, more documentation, more UI improvements like accessibility. So again AI would be assisting the team, but not as a junior level developer but as a mechanistic team member.

Like (2)

Reply (1)

Share

Rad's avatar

Rad

Mar 20

Liked by Addy Osmani

Exactly, one example would be writing unit tests for shared utilities. We all know we should do it but sometimes you have to move quick or cut corners or simply forget. With AI it is much easier to create a decent set of test cases for those methods very fast. The context of unit tests is usually very small, no global state or global dependencies (hopefully). They are also quick to run and iterate on. So there is no excuse now to avoid writing those :)

Like (1)

Reply

Share

Kristine's avatar

Kristine

Jan 1

This needs to be mandatory reading for business decision makers too eager to replace engineering with AI because cHaTgPt CaN dO iT cHeApEr

Like (2)

Reply

Share

Indigenius's avatar

Indigenius

Dec 26

The problem with this 70/30 BS that is considered “frustrating” is dumbasses are entrusting a program (it is NOT artificial nor intelliegent) to produce something that is an idea in your mind and expect a simple fucking program to somehow dreamweaver shoehorn your idea into reality and it’s fucking retarded. Programs that write proams will NEVER be artifical and will only EVER be as intelligent as the dumbass who wrote the program. Stop calling BASIC writable prigrams A. I. becaise they are niether artificial nor intelligent. Learn the damn coding and do the fucking work or pay somebody who already has. That’s the only fucking solution welcome to reality. You actually have to be worth a shit before claiming to be worth a shit. Everybody wants to claim a title but EVERYBODY is too stupid and too lazy to do the fucking work. Unfuck your heads from your asses and put in the effort or STFU and stop claiming to be something you are not and never will be you poser Fiverrs.

Like (2)

Reply (1)

Share

Duhai Alshukaili's avatar

Duhai Alshukaili

Jan 7

:)

Like

Reply

Share

Peebo Preboskenes's avatar

Peebo Preboskenes

Jan 8

"Remember: The goal isn't to write more code faster. It's to build better software. Used wisely, AI can help us do that."

Unfortunately I think AI is being used for the former more than we might want to admit.

I am about to start playing with some of these tools after avoiding them for a while. The vast majority of jobs I've worked at were what I call integration work: improving/refactoring existing code - often adding additional input guards, more sophisticated exception handling, adapting and refining requirements and integrating them into systems that are often orthogonally designed, and generally enhancing already mature or semi-mature systems.

In other words I spend far more time reading code than writing it.

I'm still not clear on how much AI can help with these tasks. Are there good AI tools for these kinds of tasks?

Like (1)

Reply

Share

Duhai Alshukaili's avatar

Duhai Alshukaili

Jan 7

This year, I conducted a small experiment with my first-year programming students. I asked them to use AI for small, defined tasks to see if it could help them become better programmers. I carefully designed prompts to ensure the responses fit a specific pattern that helps them learn. Yet, based on the experiment's outcome, only students who understood the tasks' end goals seemed to benefit from using AI.

I think one way to improve first-year programming courses is to focus more on crafting requirements for real-world software, that is, of course, in addition to getting them to understand the syntax and semantics of a programming language and learning computational thinking.

Like (1)

Reply

Share

Priteem Behera's avatar

Priteem Behera

Jan 3

It's just a matter of time before the AI is capable enough to apply real-world experience into its code. I believe we are not very far.

Like (1)

Reply

Share

Byron Wright's avatar

Byron Wright

Jan 1

Excellent read, this nailed it on the head. As a senior software engineer, I know what to ask the LLM, I know when it's wrong or leading me in the wrong direction. I find LLMs useful for those things you know but forgot the syntax for, and searching Google takes too long. Or mundane little tasks within the context of a big project, such as "Write me a shell script with parameters to...". My experience reflects this article. LLMs are just a tool. You still need actual skill and expertise to make something production-worthy truly. SWE's are pretty safe for a while.

If you think about it, until we have AGI, LLMs can only be as good as the data that went into it. Well, that data was created by humans. It's full of mistakes, bad practices, poor performance, etc. LLMs need to be constantly fed new data; if we don't get better, LLMs don't get better.

Like (1)

Reply

Share

Onur Dabakoglu's avatar

Onur Dabakoglu

Dec 30

You absolutely summarized my whole experince with these tools. They are good guides but not covering all processes of software development. It is very promising, looking forward to see where it is gonna go !!

Like (1)

Reply

Share

Zac Beckman's avatar

Zac Beckman

Dec 24

"AI is like having a very eager junior developer on your team." I absolutely love that analogy. You've made the root problem very accessible. Fantastic article, Addy... super informative. I'm going back to edit one of my own and add a reference (https://blog.bosslogic.com/p/planning-ahead-build-your-ai-readiness-plan), you've got some fantastic use cases and explanations here.

Like (1)

Reply

Share

Austin Morrissey's avatar

Austin Morrissey

Dec 24

the tidbit on useful patterns is helpful, thanks!

Like (1)

Reply

Share

jasmeen's avatar

jasmeen

Dec 14Edited

Im making over 13k BUCKS a month working part time. I kept hearing other people tell me how much money they can make online so I decided to look into it. Well, it was all true and has totally changed my life. This is what I do....quicksrich.blogspot.com

Like (1)

Reply

Share

Sean S Ibhawat's avatar

Sean S Ibhawat

Dec 13

Very interesting topic that many people are not talking about. Many various points made throughout the post questioning the aspect of speed utilization factor of AI.

Like (1)

Reply

Share

Vinod Ralh's avatar

Vinod Ralh

Dec 11

Great article! I think there’s a lot to be said about using it when testing as well.

Like (1)

Reply

Share

Shawn Flahave's avatar

Shawn Flahave

Dec 7

well said!

Like (1)

Reply

Share

Paskal van Lomm's avatar

Paskal van Lomm

Dec 6

Great story and must read for all managers and executives that see AI-assisted coding as a solution for all software development challenges :-)

Like (1)

Reply

Share

zaki's avatar

zaki

Dec 5

Thanks for writing this! It makes a ton of sense to start with the iterators and then slowly move towards the bootstrapers once you get a feel of where the AI falls short. I recently wrote a similar post with a different angle: i think the task based AIs are either a "genie" (bootstrap) or a copilot (iterator). And this concept goes beyond just coding and into other products that adapt AI. https://open.substack.com/pub/meetzaki/p/the-genie-and-the-copilot?r=exvp&utm_campaign=post&utm_medium=web

Like (1)

Reply

Share

CFV's avatar

CFV

Mar 24

And so it has been since code generators and software automation in the 1980/1990s.

The real lesson is what happens when real coding experience dies out? How will new coders really learn to fill in the shortcomings of AI generated code. Or will AI code evolve to perfection?

Like

Reply

Share

GreyNeurons's avatar

GreyNeurons

Mar 23

Nice article.

AI is definitely going to change software development for sure. It's going to impact our Young Devs more then then Senior Devs. Overall the Devs will become more of system integrators, testers and orchestrators. Along with Critical Thinking , Design and System thinking will become a critical skillsets for Devs.

I have jotted some more thoughts on this at https://medium.com/@rkanade/the-ai-revolution-in-software-development-why-thinking-matters-more-than-typing-a85ee56d3d2e

Like

Reply

Share

Philipp's avatar

Philipp

Mar 21

I love the design of your thumbnail.

Like

Reply

Share

Kevin Kulics's avatar

Kevin Kulics

Mar 21

I liked the article, but maybe I'm missing something. This is stated at the end of the article..."The goal isn't to write more code faster. It's to build better software." Of course we don't simply want to write more code faster. It's not about how much code is written. Just like it's foolish to evaluate engineers on the amount of code they write. BUT, to me this is about building better software faster. I'm not sure what Addy left out faster. If AI doesn't make us more efficient then then value is greatly diminished.

Like

Reply

Share

Edward L Cole's avatar

Edward L Cole

Mar 20

I am not a high language programmer. All I know is from programming using one of the first IBM personal computers that I played around with. The commands for Basic, Basic and the machine code where given in the manual. Today's programs could not be written in these languages because it would take way to long (Lifetimes of work), but any program could be written in these basic languages if it where not for the limitations of time and human ability. I think programmers need to be able to THINK the way someone must think to program in low-level programming languages or they will not be able to understand some thing.

I have recently begun to wonder if programmers that only know high level languages can write good programs after thinking about the AI I see on the internet. This is from the view of someone who has never worked as a programmer but I UNDERSTOOD the code given in the first IBM personal computers manual. I wrote an assembler in machine code that worked. It was a lot of busy work so I understand the limitations of low-level programming languages but I think the best programs have to be able to understand and program in a low-level programming languages.

There must be a lot of different kinds of AI but the AI I have access to on the internet often does not know what I am asking. Although it would be a lot of work I think AI used on the internet could be made to work much better if the programmers understood English Grammar and where good programmers. May be AI is not better than it is, is because those in control of the internet have there own agenda and are not interested in what people want, need, allowing people to make their own decisions, or the truth.

The programs that company's use to decide how a package will be sent to a customer have no way to override the decision of the computer. In Bryn Athyn The Post Office does not deliver to street addresses. If there is not P. O. Box number the package gets sent back. If a package gets sent by UPS Ground or FedEx ground, UPS and FedEx will say they can not deliver to a P. O. Box if P. O. Box is in the address. In Bryn Athyn People put # in front of the Box number and leave P. O. out of the address and this gets around the problem. Still sometime I want my package deliver to my street address but the AIs these companies use will not let me choose how a package is sent to me and often will not even tell me how it will be sent. The AIs use do NOT understand that it is no barge to get the best postal rate if the package will be sent back. Programmers could fix this. The US government could also do something about this.

Sometime today it is almost impossible to find the truth about some thing. The internet is getting worse and worse. Programmers need to be able to think (understand low-level programming languages) and they need to stop trying to make all of the decisions for people using AI. Computer do not know all the fact that a person know about their situation (like the situation with the Bryn Athyn Post Office). As a consumer I do not like dealing with companies that will not talk to me on the phone. These company are usually very inflexible. I would like a lot less AI in many situations. AI can not replace humans and enthusiastic AI programmers need to know AI is not the answer to everything..

Expand full comment

Like

Reply

Share

Göktürk Büyüktuna's avatar

Göktürk Büyüktuna

Mar 6

This is truly one of the most insightful and thoughtful articles I read among all the hype. Majority of the people on the internet are just letting unfounded anxiety take over their craft and ability to think critically. The “AI kills software” mentality needs to shift to a more thoughtful perspective like this

Like

Reply

Share

Nikhil's avatar

Nikhil

Mar 5

Hi Addy,

I m using AI assistant for building applications but as you said, I am struggling with that 30% in debugging and troubleshooting. Most of the code i generated seems complex than actualy the way i think

Like

Reply

Share

max's avatar

max

Mar 4

Its really a quick way to copy and paste some code you found on Github or a dev site. I find the more you try and get it to build something the more you start refactoring it, then it gets to a point where you say, WTF am I doing. And the amount of mistakes it makes is really high, and the unit tests it writes to test its own code are pretty poor. Good for repetitive task you don't like doing, or something you forgot, apart from that, its about as good as a junior going on intermediate dev, at best, you know, the ones you keep telling to keep there code clean and shiny.

Like

Reply

Share

Johny "One" Purple's avatar

Johny "One" Purple

Mar 4

So true:) protoryping? Good. Req, specs, high level architecture, great... going into detail? Nightmare....

Like

Reply

Share

Evan's avatar

Evan

Mar 1

I've experienced the one step forward two steps back phenomenon with Copilot a lot.

Now I'll just ask it to give an explanation instead of "fix it" unless it is a small syntactic error.

Like

Reply

Share

Jeff Morhous 🦾's avatar

Jeff Morhous 🦾

Feb 26

The “trust but verify” pattern is my favorite

Like

Reply

Share

Rohan Sharma's avatar

Rohan Sharma

Feb 24

Great insights! As a consultant who occasionally dives into coding (often at the worst possible times), tools like custom GPTs for debugging and RAG for real-time data have been game-changers. The tips here are valuable—I’ve wasted hours on Stack Overflow threads that an AI agent could’ve solved in minutes. Thanks for sharing!

I actually wrote a Substack piece diving deeper into how consultants can use these tools ethically to save hours/week.

https://open.substack.com/pub/blueprinttovalue/p/game-changing-llm-practices-every?r=3q6yj5&utm_campaign=post&utm_medium=web

Like

Reply

Share

Fukitol's avatar

Fukitol

Feb 22Edited

Yeah, the LLM can throw together intern-grade code in minutes where an intern would take days. But for anything non-trivial, it's going to require hours of high-level architectural and line-by-line examination, testing, and fixing before it's complete and correct. In the same time I could have written it correctly myself.

And here's the thing: while it might be low value, low complexity code I'd normally hand off to a junior/intern, if I have to spend as much time fixing it or asking for corrections as I would doing it myself, it's not saving me any time or attention.

That might be okay if it was a human, because the human would learn something from the process, so it would be time invested in helping that person grow as a programmer, who would then go on to more valuable contributions in the future. Iterate over a few years and you go from a barely-useful intern to an integral member of the team.

Not so with the LLM, which will repeat the same kinds of mistakes (or wholly different ones) next time, and the time after that, having learned nothing because it's incapable of learning during inference. And so on until the vendor releases a new model, which we cross our fingers and hope is substantially better (usually leading to disappointment).

RE: the 70/30 thing, yes, this is the old 80/20 trope, 80% functional is 20% of the work. Anyone with sufficient experience can throw together a janky proof of concept, and do it very quickly with rapid prototyping libs/frameworks and code generation tooling, which exist in most languages for most use-cases. LLMs don't bring radically new capabilities here. It's more of a generalized tool that solves a class of problems relatively poorly. The spork of prototyping tooling.

I'm waiting with bells on for "AI" tools that actually save me time and trouble. Really, I am. But the relationship between LLM utility and human skill is less as you described - inverse - and more like a bell curve, with senior programmers (those with around 5-10 years of practical experience) getting the most out of it, and mastery beyond senior level getting decreasing utility. *But* those senior devs and the teams they work with would be better served by being assigned a few interns/juniors to do the same work the LLM could do. The senior learns to mentor, the junior grows into a senior. It's a virtuous cycle instead of a dead-end shortcut that depends on a disinterested 3rd party for improvements.

Like

Reply

Share

Wasay Saeed's avatar

Wasay Saeed

Feb 21

Brilliant article and an important paradigm. AI is supposed to increase productivity, however, it assumes a completely static image of the labour force. Tomorrow's experts are today's juniors, and AI is consuming the junior roles altogether. Multiplication was a gruesome experience in school—we already have calculators, why learn this, but obviously it was indispensible to learn, and functionally, if you can't do basic multiplication you can't do anything else. However, with more powerful AI you can achieve a lot, so the need to learn to be independent is lesser, and there's more freedom for people later in life to abuse these AI models. But even then, AI is a part of our life and if we can't learn to produce with it, we're screwed. The entire learning pipeline is broken, and the best I can hope for is a complete decimation of the existing ways so we can develop a new, more robust way.

Like

Reply

Share

CogInWheel77's avatar

CogInWheel77

Feb 20

I agree with 70% theory. I experienced many issues noted here myself. However, I’ve managed to build a working prototype in cursor for my page in an 1hr. In the old days it would take me about 6-8 hours to get to this point. Now I can only fine-tune it and continue to work from a point of a neatly organized boilerplate. Going back to do it by hand would be like starting to learning machine code or assembler, or going back to punch cards, which just doesn’t make sense anymore. We just need to find a way to update learning materials and find parts in programming that are worth the time to learn. Design patterns, logical structures, interoperability need to be in every developers tool belt. But we can probably ditch nuisances like what methods do what, and memorizing them. Quick prompt asking for a method reference in the time of need would be enough. Great times for creative people with ideas and imagination to be able built products easier than ever. Hard times for people who think the essence of programming is perfecting indentations.

Like

Reply

Share

Krzysiek (cziter15)'s avatar

Krzysiek (cziter15)

Feb 20

The biggest issue is that AI actually multiplies the input. If we have a creative teenager, he would be now able to create faster. I remember when I was programaming game-hacks 15 years ago, there was a knowldge barrier and you had to up-skill and experiment on your own. I learned x86 assembly thanks to this. Today... well GPT, please make function that does D3D hooking, display some menu and so on.

While MVP code generation is cool, in hacking it's usually enough. Enough to make havoc on a bigger scale. This is what fears me, as a developer, that we are going to give it ability to actually run the code on host. It's like giving a knife to a child, only because it's useful tool with hope he will use it to grow faster. This is insane and will create huge mess.

See how many posts on social media is GPT generated. Imagine agents crawling websites, who will earn money on ads then? Who will watch YouTube if there's 90% AI generated content?

It's scary, so scary that even researchers worry mind about it so much. My theory is that people tend to think that internet is purely virtual, they think that a computer can be easilly unplugged so it does not pose any threat.

Like

Reply

Share

Usman Zafar's avatar

Usman Zafar

Feb 19

Great observations and article. One thing the article fails to mention is using AI for code understanding. Often developers switch between projects and code bases, versions and even languages. To add a minor feature or most of the time to fix a defect, sometimes even a cosmetic issue. Without AI, the developer would spend many hours trying to understand the code-base, the class structure and how data flows between the system components. Where to make change to fix it correctly. Remember, you can fix the code at many levels of abstraction, but there is usually only one ideal place where the fix should go. That a senior developer or architect of the framework would know. The AI Assistance could become the architect side-kick who can quickly explain the code modules and where the major action is going on. Kind of like grep but on steroids. I believe there is quite a lot of potential to speed up such type of code/architectural analysis. And that could save almost 70% of the time to fix a defect by someone who may not be familiar with the code base. I've always wanted a tool like this when programming in low-level languages like C++/C.

Like

Reply

Share

Francisco d’Anconia's avatar

Francisco d’Anconia

Feb 19

Absolutely my experience as a 25 year engineer turned exec. I would say the lever it provides me is even greater than that provided to an engineer who actually builds software every day, but newbies using this tech and thinking they are engineers are in for a very rude awakening when their apps collide with reality.

I stopped writing code every day almost 10 years ago but I was mentored by very diligent and methodical engineers so I can look at the code produced and judge instantly whether the approach is going in the right direction or not. I can still recognize code smells even though I’m new to typescript. React and async in general is a bit of a mindfuck so I wouldn’t say that I’m able to judge yet how good my frontend codebase is but I can at least enforce the conventions and patterns that we established at the beginning. Often that’s the most important thing - just follow the pattern, make the code readable and maintainable and you’ll set yourself up for success later, whether that means transition to a human engineer or a more advanced AI. Oddly following the pattern seems to be a tough one. Lovable is very good at this, it’s basically on rails. I recently switched to Windsurf as I need a fairly complex local setup with many docker containers and a lot of orchestration. It has absolutely excelled in infrastructure. Utility scripts, dockerfiles, docker compose, it just nails the declarative style tools and has accelerated me tremendously. I basically went from knowing zero about docker to a more complex orchestration in my personal project than we are using at work in about a week. On the minus side windsurf doesn’t seem to be able to follow a pattern at all. It doesn’t follow memory, adds new modules that are duplicative of modules that are already used throughout the project, etc. the problem is clearly context discovery so I am actually going to switch to cursor now to see if its context engine is better.

Overall I have had a positive debugging experience and I think that I might be able to enhance it further using MCP which is integrated into Winsdurf now - if I instruct the agent to add a ridiculous level of console logging, like every single line, then feed the console output back in when there is an issue, it’s very good at debugging. Without that it just randomly changes things and claims the bug is fixed. I think a browser plugin that pipes that date to the MCP context plugin in the IDE could close that loop and I’m actually pretty surprised that this doesn’t exist already. In tools like Lovable that are completely web based and operate in a closed environment. In my infrastructure code windsurf actually reads the server logs using docker command line and is pretty good at finding out what’s wrong on its own. So with a little planning and going back to basics with print statement debugging I have had good results.

Like

Reply

Share

Soldeplata Saketos's avatar

Soldeplata Saketos

Feb 9

I don't agree with the comment related to "The renaissance of personal software"

> The irony? AI tools might actually enable this renaissance

Basically, I believe that personal software is not affected by the tools we use; it's affected by the passion and motivation of every single person developing anything.

AI tools might save time for the team of devs, but then the workload of the team increases, and the developers thinking they will now have more time to dedicate to attention to details and the "self-serve software" becomes a mirage because they are now flooded with more features to cover.

As always.

Like

Reply

Share

Lameck's avatar

Lameck

Feb 2

I think you outlined the same experience I have had with AI-coding. The 70% problem is real. I bet most junior devs will suffer for this.

Like

Reply

Share

Tony Nguyen's avatar

Tony Nguyen

Jan 9

Love the article so much. I will need to re-read this every month.

Like

Reply

Share

Brian Grubba's avatar

Brian Grubba

Jan 8

Great read, I hadn’t heard of some of the apps you mentioned. I personally use Copilot and am SERIOUSLY underwhelmed with its performance. It’s not even been useful at helping me debug code, often completely breaking what was initially just a little buggy. I’m never sure what people are doing when they say they use Copilot to help them build entire applications because in my experience that isn’t remotely possible.

But, I’ll keep trying. 😆

Like

Reply

Share

Drew Hoskins's avatar

Drew Hoskins

Jan 7Edited

Addy, thanks for this! It partially inspired and fed into my post, https://drewhoskins.substack.com/p/the-most-promising-ways-to-upskill, on how developers should grow their skillsets in the AI age.

I love your idea of "The renaissance of personal software" which I've reframed as "the rise of the product/engineering hybrid"--people who can code and also have time to think about users.

Taking that further, you covered how to use AI very well, so most of my post is about the *other* things people will be freed up to focus on.

Edit: Nice, you covered some of this in your next post!

Like

Reply

Share

George Kenefati's avatar

George Kenefati

Jan 7

Aha, Pareto Principle wins again.

Like

Reply

Share

Victor Dibia, PhD's avatar

Victor Dibia, PhD

Jan 6

Great article @addyosmani.

In my opinion, many of the 70% issues you highlight come from assumptions made by the model - assumptions about edge cases, the end user experience, how that app is situated in the broader ecosystem. In short the model freqently lacks context.

Winning systems of 2025 will make it easy to have all of that context more readily integrated into the human-AI co-creation process.

..

Your article covers two topics I have been pondering and have written about.

- How AI is changing the software engineering discipline - https://newsletter.victordibia.com/p/will-generative-ai-replace-software .

- How to work with AI models for software engineering tasks. https://newsletter.victordibia.com/p/developers-stop-asking-llms-genai

Like

Reply

Share

Guðlaugur Egilsson's avatar

Guðlaugur Egilsson

Jan 6

Excellent insights.

I would add naming to the list that AI is good helping with. I use AI assistance a lot to find good names for functions and classes.

Like

Reply

Share

Gaurav Singh's avatar

Gaurav Singh

Jan 4

I use GenAI primarily for writing test code and to learn or work with unfamiliar languages such as bash etc

Autocomplete is cool and does help complete code reasonably well, sometimes acting in weird ways

ways

Chat is good to brainstorm solutions or to identify what may be missing. Generated code via chat is usually spot on but again sometimes just plain wrong.

I also have a concern that over reliance on these tools may be making me dumber and cause me to not understand syntax well enough, but then IDE and higher level programming languages have been doing that since years anyways

anyways

I fear for the n00b engineer who accepts suggestions without really understanding what its talking about.

I'm writing a series on how AI could be used for testing tasks, so if you are interested in reading my take on it, do subscribe:

https://newsletter.automationhacks.io/p/ai-for-testing-1-gen-ai-and-test-design-supercharge-your-prompting-skills

Like

Reply

Share

Romain Jourdan's avatar

Romain Jourdan

Jan 2

Good article, thanks for sharing. I am in touch with thousands of developers around the world, I see the transformation that is happening. I am a big believer that AI companions are changing the way we build software, but it is a tool, not an engineer. Developers need to learn how to best use the tool first.

Like

Reply

Share

Ivan Kusalic's avatar

Ivan Kusalic

Dec 30

Great read! Optimistic while grounded in reality.

I've recently explored this from an unusual angle - as a seasoned engineer, who hadn't coded in 7 years, using AI to get back into programming. The experience really validated your points. AI proved extremely useful to assist with coding in a new programming language. At the same time, my deep software engineering background was crucial for guiding the AI effectively. It highlighted how AI can be a powerful tool when combined with existing expertise.

I wrote about my full experiment at https://www.ivankusalic.com/executive-coder-experiment/

Like

Reply

Share

User's avatar

Comment deleted

Jan 2

Comment deleted

jeax's avatar

jeax

Jan 2

Agree.

Like

Reply