How to Become a Jedi at “Vibe Coding” So You Can Level Up to “Vibe Engineer”

A Detailed Guide to AI-Assisted Developer Workflow

This post is a summary of a talk given in June 2025 to shift the mindset of those involved in AI-assisted coding. It is also revisiting the topics of Why The Future Is All Code, But No Coders, and When AI Finally Writes All the Code, What Will Us Developers Do? I first wrote in 2023. It's the single longest article I’ve written to date on Medium, but it’s also the most complex emerging topic. I promise that the half hour it takes to read this article will pay back over time if you start applying its practices of “Vibe Engineering”.

For those new to AI-assisted coding, who have only used it as “auto-complete on steroids” or perhaps not at all, looking at recent claims from the outside should leave you skeptical. I do think “vibe coding” in the sense that you should “forget the code exists” is absurd for non-trivial projects; however, I remain steadfast in my belief that this is at least on the level of “the next code scaffolder” if not “the next level in code abstraction”. When used correctly, it’s like wielding The Force, but looking at the industry at large, I fear it’s falling to The Dark Side — these ideas are my guess at what might turn us back to The Light.

The Inner & Outer Loop of Software Development

There are moment-to-moment developer actions that make incremental progress on the code, and hour-to-hour activities that teams undertake to advance the project. These are commonly referred to as the “inner” and “outer” loops of software development. These two gears interlock to create a repeatable process that can not only be followed and monitored but also improved and automated.

A wheel within a wheel on an ever-spinning reel; graphic by Curiosity

The most confounding factor in this process is human, most critically, the coordination of resources and the effectiveness with which we express customer needs into working code. The most profound perspective on this process is that there's no trade-off between speed and quality when moving through these loops; therefore, it’s not about defining a better roadmap so much as being able to turn and accelerate, regardless of the direction your customer's needs drive your project.

What is a developer doing when iterating on the inner loop, and how might AI help accelerate that cycle? Most importantly, the rapid pace of GitHub Copilot code generation has created “downward pressure on code quality”. The rapid 70% of AI-powered development still leaves a vexing 30% of problems to solve with knowledge and craft. While tasks are completed much faster, there is a verifiable trade-off in reuse, modularity, and brevity. What conscious habits might fight against this phenomenon?

Version Loop

Aside from the most primitive of PHP script kiddies, every developer should be familiar with version control. If you can’t git add, git commit, git push, and git reset but are trying out vibe coding with serious intent to ship to production, then you need to get back to basics as a developer. If you’re smart, you can be lazy, but if you’re lazy, you’ll never be smart. Assuming you are familiar with the basics of git, there are a few key points to consider when using it to work effectively with AI tools.

At a basic level, AI tools generate a significant amount of code quickly, and version control is your tool for reviewing and managing those changes. AI code can turn into a random pile of black boxes if you don’t review and understand each change, so look directly at your diffs often and stop to research any mysterious changes.

Get familiar with the git capabilities, especially easy and visual diffs, that your editor offers. I’ve learned VS Code git features to a new depth that is helpful in all development. At a basic level, get comfortable with git branch whenever you start a new step in your implementation and git commit often. I believe you can also justify a git commit --no-verify in a branch as long as you don’t do that while merging that branch back into your main.

Version control is your ripcord in the short term, ensuring the current change can’t dead-end you into a bug. Your prompts require iteration while you’re building them, and while you could try and retry on the current changes, it’s almost always better to git reset head --hard then rebuild your prompt to try again. Consider saving those refined prompts in some way, such as commenting the prompt at the top of a key file that has been created, much like another form of source code.

Version control is your trail of breadcrumbs in the long term, giving you insurance if the foundation slowly turns to mush under your feet as you make progress over multiple features. Perhaps the library Copilot selected an hour ago doesn’t yield the desired outcome three features later. The good news is that if you have several diffs over those hours to reference, you can create a new branch based on the oldest beneficial change, then correct the context and rerun the intermediary prompts to achieve a similar result with an improved likelihood of long-term success.

Another specific technique would be a git hook on pre-commit that performs basic checks on the code, such as linting, unit testing, compilation, and dependency checking. For instance, a Typescript node/deno project using pnpm might have a git hook managed by Husky that runs a command like:

pnpm lint && pnpm test && tsc --noEmit && depcheck

Making the AI agent aware of such commands in your repository, such as in the package.json of a Node or Deno project, can also become valuable input to agentic coding tools we’ll explore later. This level of basic checking also lends itself smoothly to the next best practice: TDD.

Test-Driven Development (TDD) Loop

To some extent, a prompt is a set of requirements with implied questions that are “answered” by the AI tool. How do you know the code is the right answer if you’ve never defined the problem? Test-driven development is an incremental approach to code design, considering how to create code that is not only easy to write but also easy to consume.

Test-Driven Development (TDD) was initially developed by Kent Beck in the 1990s as part of eXtreme Programming (XP), and represents a still durable paradigm. For anyone unfamiliar, it centers on writing the unit tests for a new behavior before making that behavior, ensuring they fail, then writing the behavior to satisfy the test. Finally, one introduces modularity to the code only after the fact, breaking up the creative flow into solving the epistemic problems before the functional ones.

For audio/visual learners, Dave Farley offers a compelling description and argument for TDD on YouTube and it is one of his eternal drums he always beats. He is the first person whom I ever heard say “red-green-refactor”, so my mind’s ear always hears it in his voice.

Most specifically, the “Red-Green-Refactor” model aligns very nicely with an AI workflow, as it expands and contracts the AI's responsibility to suit its strengths. It means the structure and validity is about having the AI write code faster, writing the logic constructively engages more creative problem-solving in the AI, then refactoring puts you back in the driver’s seat for improved modularity. GitHub Copilot’s agent will also often automatically run the unit tests after it generates code, making tests a valuable technique to make the agent independent in its flow. What do I mean by agent mode? Glad you asked.

Agent Loop

In February, GitHub Copilot introduced its new agent mode, “the next evolution in AI-assisted coding”. At first, it may seem like simply Edit mode on steroids in that it can look at the entire codebase and act on more than one file at a time; however, it’s a leap beyond that. It moves from having a conversation that makes code to having a conversation that does actual application development.

Working with Agent Mode still has some key best practices to keep in mind. First off, communicating with the agent in a style of chat that is more expansive than “write this code for this class”, such as a prompt that describes requirements to discuss a change before enacting it. When chatting, think of it as a full AI partner for pair programming.

The resulting code change spans multiple files and can be more sophisticated than just auto-completes or edits, which means you are more dependent on ensuring you can effectively diff the changes. When making changes, VS Code offers a built-in diff mode that acts like a local Pull Request, where you can “Keep” or “Undo” the changes in seconds.

There are several key considerations to keep in mind once you reach this scale of changes. First off, the longer the conversation goes on, the more likely it becomes that the agent’s context will clutter with so many ideas it starts leading you in the wrong direction. Thus, clearing the chat (in VS Code, that’s as easy as clicking the “+” at the top of the chat window) when you reach the code you need — especially when you change topics — is critical.

Working with agents greatly expands the range of tasks you can accomplish, but it will also put into stark relief whether your programmer's prompt engineering skills are keeping up. For a practical guide on improving your prompts, consider The Prompt Engineering Playbook by Addy Osmani as a starting point. While the article itself is written more like you’re conversing with ChatGPT, the agent mode will enable your improved prompts to run in the context of your prompt with much more ability and accuracy because you leveled up your communication with the AI.

Providing better inputs to your tool will lead to better results. Are there inputs beyond single conversations? If we’re clearing it constantly, how do we get the AI to write code beyond one step at a time without relying on copy-paste prompts all the time?

Prompt Loop

Interactions with the agent provide productivity for minutes at a time, but there are a few ways to deliver timeless enhancements to every conversation with the Agent. Furthermore, some techniques enable the agent to work across multiple interactions, yielding more reliable output and a clearer roadmap for progress. It’s like creating a more intelligent bot with a more diverse toolset, akin to transitioning from viewing GitHub Copilot as a coding backhoe to having it at your side like R2-D2.

At Build 2025 in May, I first learned about GitHub Copilot instructions, which is a way to have Copilot read from a local, repo-level, or organization-level file on every conversation that guides its actions. For instance, an instruction file might summarize the nature of the application and its tech stack.

More advanced scenarios include integrating other files into the project, such that Copilot constantly outputs its thinking or has an explicit strategy for understanding the project's structure to work more accurately. They are pre-baked contexts for your conversations and context is king when prompting LLMs. These context are most often saved and understood as Markdown files that are the happy medium between human and machine readable.

For the longest time, I kept text files or GitHub Gists of prompts that I would copy and paste, then customize to achieve specific outcomes with ChatGPT or Copilot. The GitHub team finally added saved prompts, which, similar to instructions, allow you to store a prompt like a subroutine and call it from chat by reference. They can be technology and use case specific, such as a saved prompt to make your iOS app’s unit tests for you or be chained together almost like a framework for productivity. It’s an evolution to have a ready toolbox with hammer, screwdriver, and drill, but a revolution to connect such pieces into a mini-factory for with a conveyor belt of progress.

I would summarize this approach using sets of saved prompts and intermediary Markdown files, similar to the “AI Prompt Programming Framework”. It should always start with precise requirements, which represent an acorn of understanding, the exact quality and clarity of which will guide success. The prompts are just fertilizer, not the DNA for the product you are about to grow.

Pierce Boggan shared such a framework at Microsoft Build 2025, which can be broken down to reveal its components. It’s not necessarily a definitive implementation of such a framework. Still, it models the correct direction by demonstrating an iOS application built through a real iterative process, rather than simply “giving in to exponentials”.

GitHub — pierceboggan/Dropped: AI cycling training app

Hix example is the most robust design pattern I’ve seen for graduating from a bundle of clever prompts to a real process:

The GitHub Copilot configuration is held in a folder named .github in the project, which seems to upset Medium.com’s security, so you’ll have to cross-reference the contents of the ./github/promptsfolder in the repo linked above with the names of the prompts here, but I can link to the markdown output of the prompt, so I have linked the output of the prompt rather than the prompt itself. The output of “Implement” is the code in the project itself.

• New — A prompt for writing requirements for your app in a known format, like a Product Requirements Document, as a markdown file, and add it to your repo. On a team, this process likely begins with a person in a Product role who collaborates with other stakeholders (and perhaps uses a standalone chat tool like ChatGPT). Pro tip: I’ve encountered numerous situations with ChatGPT output and Word documents alike where it’s best to use a tool to convert rich text to Markdown to integrate it into the developer workflow
• Spec — A prompt for converting broad requirements into specifications for the application into yet another markdown file, making a gentle transition from the fantasy of the requirements to the reality of the code.
• Plan — Most critically, a prompt that converts the cumulative content into a multi-step plan, allowing subsequent work to follow and iteratively build upon the code over time. The markdown file becomes a literal checklist for writing the code. Ideally, this would include TDD practices; however, none of the example outputs in this project follow such patterns. Most importantly, it means you have a clear way to segment the multiple conversations where you chat-code-keep-clear in the “Agent Loop” without losing ongoing context for the agent.
• Implement — Move item by item in the plan and make changes to the source code in the repository.

To best understand this example framework, watch the video of the Microsoft Build 2025 session, Agent Mode in Action: AI Coding with Vibe and Spec-Driven Flows. Watching it completely broke through my resistance to taking “vibe coding” seriously because I could now see how there is a professional-grade process for “Vibe Engineering”. We’re not here for AI to make our code for us; we’re here to define the “AI SDLC” so the bottomless hype can be replaced with raising the bar.

The Vibe Loop

Using the Version loop as a foundation, one can then transition between the TDD, Agent, and Prompt loops, utilizing manual, automated, or AI-powered coding to achieve outcomes more efficiently. Understanding when to use each, perfecting prompt engineering, and integrating human-in-the-loop throughout the process is more art than science for me; however, I do believe personal habits in development akin to these practices represent the inevitable evolution of programming.

I’ve been refining them over the last couple of months, and I can see how the skill ceiling is higher than I may be able to reach until I’ve delivered several features and apps using the techniques, not dissimilar from learning a whole new programming language or framework. In this case, it’s just English and spec-driven flows.

There are still developers today who have entirely rejected Integrated Development Environment (IDE) tools and will give you breathless explanations as to why you need only 20% of an IDE to get 80% of the benefit. Even those people will have stripped-down options like GitHub Copilot for Neovim, Claude Code, and Gemini CLI.

Hipster energy for 100% local, organic, vegan code will doubtlessly ripple through meetups and message boards into the future; however, it will be fueled by ignorance or cynicism. It may even be the case that you need to have proficiency in the top 10% of the tools and processes to reap durable 10x benefits from them, but all the more reason to become not just a padawan but a master. Don’t believe the hype, but do get curious about the possibilities.

AI on the Outer Loop

The description above is a practice for local development on the “inner loop”. There is also an emerging generation of tools on the “Outer Loop” that are designed to run in the cloud. Admittedly, they are beyond the scope of both this article and my experience, but since I first heard Satya mention GitHub Coding Agent back in May, I’ve been eagerly waiting for the right moment to try it.

Satya’s first PR in a while

I’ve used tools that check dependencies and scan for security holes, automatically generating Pull Requests for your codebase before, so this seems like the next logical step. Even more so, I can imagine a future where these coding agents can take much more varied input — say the transcript of a meeting where you discuss a feature with a product owner — then output draft requirements AND code changes to align with it. Not because I think it will work the first time and replace human labor, but because “Plan to Throw One Away” has been great advice for 50 years. We can finally throw away code faster than we could ever write it before — and that’s the biggest advantage!

GitHub Copilot in Agent Mode on the inner loop; GitHub Copilot Coding Agent on the outer loop — nothing confusing about those names at all

I believe the real patterns and practices of “Vibe Coding” are not going to make you forget the code exists, as much as make you think about it in whole new ways. It means developing work habits that enable easy recovery from dead ends and rapid iteration on good ideas, as we’ve been trying to evangelize in the industry for decades. It means emphasizing quality as the key enabler of speed in a project, not just something we “do later because we have to”. All told, it means this is a new layer that turns natural language into code, it’s a new form of Metaprogramming that requires a new self-awareness about our habits.

The Vibe Loop by Example

The description of the four-part “Vibe Loop” may be abstract so far, so here is an end-to-end example for anyone who wants an explicit path for development. These steps may be instantly antiquated after July 2025, but this article is intended for those aspiring to be “vibe engineers” rather than just “vibe coders” and engineers like clear instructions and examples. I identify the type of “loop” each technique represents in these linear steps for generic feature development, which are meant to be loosely followed from top to bottom. I am ignoring “AI on the Outer Loop” as it remains theoretical to me as of this writing.

There is no single step dealing with “Instructions” from the “Prompt Loop”. At each “Prompt Loop” and “Agent Loop” step, you may examine and refine your instructions before, during, and after to ensure the outputs align with the goals and constraints of your app and its tech stack. Often, when you encounter a thematic bug in the generation of your markdown files or code, the real root cause lies in the instructions or saved prompts. Consider making changes to the current scope, but do so infrequently, as these modifications should apply to any current or future feature development. This approach is more akin to modifying your underlying open-source framework than just fixing a minor bug in your code.

• Version Loop: Make a new local branch in git with git branch. Many teams use Feature Branch Workflow by default, so this step may be required practice on your team to ensure reviews. Even if you’ve graduated to trunk-based development, I still prefer making a local branch when working with an AI tool, given how disposable the current chain of commits becomes with your rapid pace of development.
• Prompt Loop: Consider the requirements at hand, which should be concise yet clear, produced by a mature Product process. How might you best convey human understanding with the most robust acorn of wisdom? I don’t know yet. Just make sure you do your best to get what you have into a markdown file. Use a stored prompt to break down feature-specific requirements into one or more markdown files you can examine, edit, and iterate upon with the agent — ideally telling it to “ask questions when confused” and “don’t write code until you’re 90% of better confidence” or similar commands to make it a process of collaborate problem-solving rather than simply expansion from English to equivalent code.
• Version Loop: git add . && git commit. to save your requirements and related intermediary markdown files, most criticially a plan that acts like a checklist of actions over many conversations with the agent rather than counting on your brain to do that guidance
• Agent Loop: When building a single step in your app, succinctly define one or more interfaces that encapsulate the solution to the problem. You can iterate with the tool in a chat-only mode that won’t generate code immediately, such as using GitHub Copilot’s Ask mode. If, at this point, you can think in terms of SOLID principles and design patterns, then great. However, the goal right now is to craft the simplest contract for a solution based on the consumer's context, not to create a perfectly modular piece of code yet.
• TDD Loop: Once you have a testable structure, many people handcraft unit tests, but you could have the AI swiftly scaffold unit tests that cover positive, negative, and edge cases for each method or useful constellation of methods. In GitHub Copilot, you can do this in “Edit” mode to make a single file, referencing any requirements markdown you may have and implicitly using instructions relevant to the context.
• Version Loop: This test should initially fail (as expected), so if you want to commit it, try git add . && git commit --no-verify assuming you have git hooks enabled that run unit tests. Your CI/CD pipeline should complain wildly about this change if the change somehow ends up pushed up without finishing the “green-refactor”
• Prompt Loop: Now that you know what success looks like, you can create an implementation of the class by providing not only the context of a saved prompt, requirements, and plan but also referencing the unit tests to consider how the class is consumed. This enables a higher level of problem-solving and instant assurance that the code matches the outcome. This can be best achieved using GitHub Copilot in agent mode, especially with a more powerful model that may have a higher cost, but greater capability. Since you already made unit tests, the agent can even iterate on its own to satisfy them. Ensure you understand the code and its dependencies! More on that below.
• Version Loop:git add . && git commit to save your progress, which should include passing unit tests after the implementation
• Agent Loop: You now revisit the code from top to bottom to consider modularity and best practices. This is where you make the code completely SOLID and secure with extensible design patterns. This is another moment to do things more manually, but agent mode can enact a lot of the change at your command. It may be valuable to keep the same Agent mode chat going for this step, especially if it wasn’t a long journey to create the code, as it often provides extra context. However, you may consider swapping to Ask to help with brainstorming and save costs, eliminating what may have been a confusing journey for that chat.
• Version Loop:git add . && git commit to capture your completed progress through red-green-refactor. Now that you have a branch of code that was written and reviewed incrementally do one last comparison between your new and main branches. git diff or use your favorite visual tool to compare branches. If you use Feature Branching, then git pushthen make a PR to get your AI collaboration into peer review. If you’re using trunk-based development, then do something akin to git checkout trunk && git pull && git merge feature-branchrolling your changes in. You likely should resist the urge to squash since that detailed merge history is a valuable lifeline if you’ve accidentally started on a dead end and don’t realize it until later.

Congratulations, you have made several revolutions around each loop, delivering a valuable unit of work for your application!

More than likely, you hand-wrote more of the code than I even described in this short example, and there is an inexorable need to understand and explain the problem with a clarity that never really makes it “easier” so much as “potentially faster”. Code is still more art than science when you’re making it line by line. The brush in this case was just the paint sprayer of an LLM, which is hopefully still just enabling you to touch.

What About The Debug Loop?

Now the elephant in the room: Did following all these loops lead to better software faster, or did you go around in circles? Several times throughout this process, you had to engage in the as-yet-ignored and still undefined “Debug Loop” of programming, which is only exacerbated by AI tools. This is the most volatile area, and I hesitate to attempt a definitive framework for it.

The common complaint of “I could have made the code in the same time or less it took to prompt for the code” will become your reality in some cases. There is a certain “AI Coding Escape Velocity” that requires knowledge of the tools, plus a sense of when and how to use them, which even escapes me at the moment. For my part, I know I am achieving faster success of equal or greater quality at an increasing rate, and I am committed to overcoming all obstacles to master the new metaprogramming, even if that means struggling with metadebugging.

Instead of defining the “Debug Loop” right now, I would encourage the reader to follow Addy Osmani on Substack who not only writes about the challenges of AI code productivity and quality but also provides practical guides on “Debugging” as a broad topic that is more relevant than ever, and specifically on “Vibe Debugging”. Furthermore, we are a month away from him publishing the first book in Vibe Coding that will likely be worth reading: Beyond Vibe Coding.

Good Vibes Only?

Of course, the most paramount question becomes: How do I know the AI made the Right Thing? How do I know the AI made It Right? Which is where the double-edged sword of vibe coding becomes sharpest. AI Tools allow for rapid iteration by even non-professional programmers; however, the marketing message and industry excitement to “democratize coding” must be counterbalanced by increasing concern for real-world software concerns, the moment one is making applications beyond toys.

Real concerns for AI-generated broadly fall into the categories of “non-software concerns for your business” and “non-functional requirements for your software”, for instance:

• Is this stolen code? This is the most vexing to verify. Furthermore, many non-trivial UX interactions are covered by software patents, which expose your code to patent trolls, even if you only have open-source code. We may be slowly entering an era of murky IP, where a generation of companies is met with legal resistance (patent trolls like never before!) upon success, especially when attempting to sell the company.
• Is this a sustainable Software Development Life Cycle (SDLC)? For instance, the highest-level AI tools, like Bolt.new or Loveable, offer the fastest and most miraculous path from prompt to live application; however, they don’t guide you down a path of having a deployment pipeline with automated testing, multiple environments, or monitoring of your application. Fast-to-write code will not have the ongoing agility for your product that a fully engineered process has, where speed and quality are inextricably entangled. If you want one, you must have both.
• Is this code secure? AI code is often written from getting-started examples that expose security keys or exhibit outright behavioral bugs that aren’t best practices. If you can’t write secure code from scratch, good luck trying to understand it when it arrives hundreds of lines at a time. Consult the OWASP Top 10. Consider whether your code addresses any of the key vulnerable areas of a project, such as authentication, cryptography, or cloud resource configuration. Is there any access to a data source, and are you checking role-based access policies along the way? Has your team implemented a Static Application Security Testing (SAST) tool?
• Is this configuration secure? Adjacent to the concern above, if you’re using AI code to write configuration for your system — SQL declarations that implement row-level security, Infrastructure-as-Code (IaC) files that control your cloud resources, etc — there is a new level of architectural consideration that also means you must understanding from a foundational level what good security looks like. I once had GitHub Copilot auto-complete a CloudFormation yml template that was one asterisk away from leaving my resource open to the entire internet — had I not known, I would have pushed the code up, and I would have been trusting “security through obscurity”.
• Is this scalable? The “first 100 user” version of a component and the “first 100,000 user” version are a lot different. The AI will not account for the real performance, reliability, or portability concerns of your application without significant forethought and knowledge on your part. It’s not going to stop you mid-application and suggest converting a process to an asynchronous queue handler, bully you into implementing distributed tracing, or spot your cold start issue just by looking at your TypeScript a few files at a time. Your pursuit of short-term speed will constrain your long-term success.

If you want to build a software business, then all of the concerns above are inescapable. Especially if you’re wildly successful or in a regulated industry (such as healthcare, finance, or government), you will have to face the challenges of incorporating software engineering as a capability within your business.

For the most part, non-developers creating applications via “prompt-to-prototype” workflows should be viewed as an innovative medium for communication between product and engineering disciplines. Faster than a Figma and coupled with a completely explicit description of the underlying behavior that can form the raw ore that is refined into the real gold of the application; otherwise, the tools are churning out pyrite.

Pictured on the right: My face when my YouTube feed shows me another “Vibe Coding” video about how we’re all ten prompts away from being millionaires

The most significant opportunity for non-coders creating with these tools is that bespoke, interactive websites and free-to-use online toys could experience a mass resurgence. AI tools are great at making browser games that one could see on the next Itch.Io or novel media experiences like the next Newgrounds. There is no reason to think that a citizen-developer with AI tools cannot create local-only experiences, so the web can return to being a medium for interactive expression.

Even in the hands of experienced developers, agent-driven flows that make large amounts of code changes still have lower-level practical details to keep in mind:

• Are all of your new dependencies current and secure versions of projects that are actively maintained and have no superior successors? For instance, run npm auditor pnpm audit before accepting new dependencies, please review the project on GitHub to ensure it has commits within the last three months and more than one contributor.
• Does this code exhibit behavior that is covered by automated testing? If you’re practicing TDD, then your change should have a unit test before it’s even created. Based on known inputs, capture persistent outputs from your endpoints that you can version control and see changes alongside the code in widely captured snapshots of behavior. Higher-level testing, such as end-to-end testing, can also be created and managed by AI. For instance, Playwright tests that test in a browser and can be authored and driven by your AI coding partner. Depth and breadth of testing will take you from writing code to governing application development, critical when your app is changing at potentially 10x speed.
• Could this code be made more succinct? AI tools generate a significant amount of code, particularly layers of elements in the user interface, which can often be simplified and optimized. One of your gifts as the human-in-the-loop is your laconic taste.
• Can you explain this code to someone else without needing to ask for help from the AI? If you and I were in a meeting and answered with “let me get back to you after I ask ChatGPT” about a piece of code that does anything significant for the company, I’d let you go for being lazy instead of being smart.
• Could you fix this code if your AI tools were taken away? Not because AI tools will go away, but the economics of startups mean we may be in a golden age of competition and venture capital that is short-lived. Remember when Uber rides used to cost $4 instead of $40? The moment companies can reliably increase developer productivity 10x, they’ll raise prices by 100x to “charge for value, not cost” — or simply because they have a monopoly and no one can stop them. This will prompt small companies and large organizations to potentially rethink the cost strategy of AI developer tools in terms of OpEx efficiency, especially when coupled with a growing consensus that mediocre processes with the tools erode quality outcomes over time.

These are each examples of why the evolution of a tool doesn’t eliminate the need for taste on the other side of it. Mastering AI tools remains a noble challenge for 2025, if not a necessity. The marketing hype for AI coding may be overblown, but the industry itself is behind on adopting Agile practices that work. What new hope do we have that AI practices will fare much better? One might think “Light Side” doesn’t have “AI”, but “Dark Side” does! But both have tools that, in the right hands, are unstoppable, but in the wrong hands, will take your legs off. It’s your choice if you’ll master them or fear they’re used against you.

When a weapon in the right hands has the crew of your spaceship outnumbered 1-to-307

Like many a nerd, Erik has an extensive collection of Star Wars LEGO sets that remind him that the merger of technology and human hands organizing existing pieces can be satisfying and creative. He is also a tech innovator with 19 years of experience in the industry. Erik is also co-founder of Fuse Accelerator in the emerging community of Tri-Cities, WA, where he works on connecting people and sharing knowledge to turn new ideas into growing startups. You can find him on LinkedIn or the next Fuse event.