{"id":71633,"date":"2026-02-09T18:19:09","date_gmt":"2026-02-10T02:19:09","guid":{"rendered":"https:\/\/www.ponoko.com\/blog\/?p=71633"},"modified":"2026-02-09T18:20:51","modified_gmt":"2026-02-10T02:20:51","slug":"how-you-should-code-with-ai","status":"publish","type":"post","link":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/","title":{"rendered":"How You Should Code With AI"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Large language models have fundamentally changed how software is written, reviewed, and maintained, often faster than the industry has had time to reflect on the consequences. While AI-assisted coding can dramatically increase productivity, it has also given rise to practices that quietly undermine engineering discipline. One of the most visible is vibe coding<\/strong>, where working output is prioritized over understanding. This article examines why that approach is risky, not because AI is incapable, but because responsibility is misplaced. Drawing on real-world experience building a secure custom PHP framework, we will explore how engineers can use AI effectively without surrendering architectural control or technical judgment.<\/p>\n\n\n\n

The Age of LLMs and AI<\/h2>\n\n\n\n

I remember a few years back when ChatGPT first hit the news cycle and, almost overnight, became the subject of both fascination and sheer panic. As someone who writes technical content for a living for the electronics industry, my gut reaction was not dismissive curiosity but genuine concern.<\/p>\n\n\n\n

What struck me first was how strong its initial writing capabilities were. It could structure an argument, maintain tone, and keep it readable with alarming speed. Sure, the output was not perfect, but that was hardly a criticism worth leaning on; even humans make mistakes a times. But the difference here was that the AI could generate usable text in seconds, while a human needed time, focus, and coffee, and that alone was enough to make a lot of writers uncomfortable.<\/p>\n\n\n\n

But at the same time, its limitations were totally obvious. It would hallucinate facts, flatten out complex ideas to the point where it would loose context, and, occasionally state things with confidence that were just simply wrong (anyone remember the suggestion to use glue to keep cheese on pizza?). None of this was shocking, writing well is more than syntax and grammar, it is about judgment, subject, and understanding the audience. Still, the gap between acceptable and excellent writing felt smaller than many people were willing to admit.<\/p>\n\n\n\n

Its coding abilities, however, were a totally story. Early attempts at generating code ranged from crude to outright broken, where syntax errors were common, and logic errors even more so. It could produce snippets that looked plausible, but anything beyond trivial examples quickly fell apart. At that point, I felt some sense of relief, as while my work as an engineering content creator looked to be on shaky ground, my skills as an engineer felt safe.<\/p>\n\n\n\n

But that sense of safety did not last long.<\/p>\n\n\n\n

As public attention to ChatGPT (and AI in general) grew, so did the predictions. Coders, we were told, would be next on the chopping block. If AI could already write better than most humans, then surely coding was just a matter of time? After all, code is more structured than language, more rule-bound, more predictable. To many outside the field, it seemed inevitable that software development would be automated away entirely.<\/p>\n\n\n\n

This line of thinking made sense on the surface, but was incredibly and deeply flawed underneath. It treated coding as a purely mechanical act, a process of translating ideas into syntax. But anyone who has worked on real systems knows that this view collapses the moment things go wrong. Code is not valuable because it compiles, it\u2019s valuable because it encodes decisions about structure, responsibility, failure, and tradeoffs.<\/p>\n\n\n\n

Still, the fear was real, and far from being entirely irrational. The early success of AI in writing created an major assumption across the tech industry that coding would follow the same curve. It was very easy to imagine a future where the hard parts of software development were quietly handled by machines, leaving engineers to supervise or, worse, become redundant.<\/p>\n\n\n\n

And that assumption set the stage for what came next. Not the replacement of engineers, but the emergence of a new way of misusing powerful tools.<\/p>\n\n\n\n

AI Enters the Coding Space<\/h2>\n\n\n\n

As fast as ChatGPT rose, it didn\u2019t take long for AI to cross an important threshold and become capable of producing working code. Not complete applications or massive codebases, but discrete functions, small modules, and glue logic that could compile and run. The code output was uneven, sometimes brittle, but it was good enough to demonstrate serious potential. For the first time, many programming tasks could be completed by describing intent rather than writing syntax line by line.<\/p>\n\n\n\n

For many who were new to programming, this capability was often misunderstood. AI was not suddenly capable of producing a million lines of coherent code for the next MMO or a complex simulation system, but it could write enough code to make things appear functional. For example, a web form could submit data, an API endpoint could return a response, or a script that could automate a task. But, for many observers, that distinction did not matter, and this working output was interpreted as solved engineering.<\/p>\n\n\n\n

At this point, companies began to notice these capabilities. Now, from a managerial perspective, the appeal of an AI coding system was obvious:<\/p>\n\n\n\n

I<\/em>f AI could generate functional code quickly, then perhaps fewer engineers were needed, or at least fewer experienced ones.<\/em><\/p>\n\n\n\n

The idea was not that AI would replace entire teams overnight, but that it could reduce headcount, lower costs, and help to massively accelerate delivery. Of course, as with many technology-driven cost-saving narratives, the long-term implications were not examined particularly carefully.<\/p>\n\n\n\n

Alongside this shift, a new behaviour pattern emerged, later labelled vibe coding. While the term \u201cvibe coding\u201d is not a formal methodology or a deliberate design philosophy, it is extremely well understood by the engineering crowd and now widely accepted. But even if the term or concept of vibe coding isn\u2019t official, it is a very real thing and arose as a natural consequence of placing powerful generative tools in the hands of people without requiring a deep understanding of how software systems actually work.<\/p>\n\n\n\n

But what exactly is vibe coding?<\/p>\n\n\n\n

Vibe coding, at its core, is the practice of describing what a program should do in broad, high-level terms, accepting the generated code, and deploying it with minimal scrutiny. The emphasis is on outcome rather than structure, and speed over understanding. If the code runs, it is treated as correct. If it fails, the response is often to adjust the prompt and regenerate rather than to reason (the good old prompt \u201cdon’t produce errors\u201d, which is laughable).<\/p>\n\n\n\n

This approach has made many people feel like programmers. With enough prompting, they can create applications that look impressive on the surface and appear to solve real problems, and for simple use cases, this illusion can persist for quite some time. The problem, however, is not that the code is always bad, but that the understanding behind it is missing.<\/p>\n\n\n\n

And this is where the problems with vibe coding start.<\/p>\n\n\n\n

Why Vibe Coding Is Dangerous<\/h2>\n\n\n\n

Vibe coding is often framed as a faster and more accessible way to write software, but from an engineering perspective, it is arguably one of the most dangerous approaches currently gaining traction. Now, the risk is not that it produces code quickly, but that it does so without enforcing the discipline that complex systems require. Speed without understanding has always been a liability in engineering, and software is no exception.<\/p>\n\n\n\n

Where Vibe Coding Hate Gets It Wrong<\/h3>\n\n\n\n

Criticism of vibe coding is frequently dismissed as elitism or as frustration from experienced developers who resent newcomers. But that interpretation misses the point entirely.<\/p>\n\n\n\n

Should we hate those who use CAD or auto-routers? Should we dislike the use of tools like Google Search?<\/p>\n\n\n\n

Any new tool that is introduced often helps to make work easier, so simply hating AI for enabling more people to program is absolutely the wrong reason to do so. Thus, the real concern with vibe coding actually lies in who has control of decision making. In vibe coding, that authority solely lies inside the AI.<\/p>\n\n\n\n

The Real Reason To Shun Vibe Coding<\/h3>\n\n\n\n

The core problem of vibe coding is that architectural decisions are entirely delegated to the AI. Structure, control flow, data ownership, and error handling are not consciously designed (and considered) by the engineer, but instead inferred by the model based on statistical patterns. These architectural decisions are fundamentally critical in any application as they define how a system behaves under stress, how it fails, and how it can be safely modified over time.<\/p>\n\n\n\n

Now, AI performs well when the problem is local and bounded, for example, writing small functions, adapters, boilerplate, or performing mechanical transformations sits squarely within its strengths. Where it consistently struggles, however, is global reasoning. Defining clear boundaries, enforcing invariants across modules, and maintaining coherence as a system grows are tasks that require an explicit mental model and long-term intent.<\/p>\n\n\n\n

When structural architecture emerges implicitly from generated code rather than explicitly from design, the resulting system lacks a stable mental model. The code may compile and even pass basic tests, but it is not truly understood (either by the AI or the engineer). Understanding here does not mean being able to read the code line by line, but being able to explain why it is structured the way it is and what assumptions it relies on.<\/p>\n\n\n\n

This lack of understanding becomes a incredibly serious liability the moment something goes wrong. Debugging is not the act of finding where a failure occurs, but of reasoning about why it occurs. In vibe-coded systems, the reasoning chain often exists only in the AI\u2019s prior output rather than in the developer\u2019s head, making diagnosis slow, uncertain, and error-prone.<\/p>\n\n\n\n

As a result, failures are frequently addressed by regeneration rather than analysis. Prompts are tweaked, code is reissued, and the system is nudged back into a working state without the underlying problem ever being fully understood. This trial-and-error approach breaks down quickly in systems that involve security concerns, concurrency, performance constraints, or long-term maintenance.<\/p>\n\n\n\n

Thus, the real danger of vibe coding is not that it produces bad code immediately, it\u2019s that it produces fragile systems that appear to work until they fail in subtle or catastrophic ways. When that failure finally occurs, no one involved has a complete understanding of how the system was constructed or how to repair it with confidence.<\/p>\n\n\n\n

How to Code with AI<\/h2>\n\n\n\n

Given my criticism of vibe coding, it is reasonable to ask whether using ChatGPT daily for programming makes me a hypocrite. On the surface, the differentiation can look thin, but in practice, the workflows could not be further apart.<\/p>\n\n\n\n

After extended use, deliberate experimentation, and a critical review of my own chat history, a consistent pattern emerged. My coding process does not revolve around asking an AI to produce systems for me, but instead revolves around using AI to help support decisions I have already made.<\/p>\n\n\n\n

The Mental Model (System Architecture)<\/h3>\n\n\n\n

The fundamental separation between effective AI-assisted coding and vibe coding lies in where the mental model sits, how code is generated, and how the engineer interacts with the model. In a healthy workflow, the engineer owns the architecture, where the system\u2019s structure, constraints, and failure modes are defined first, before a single line of generated code is accepted.<\/p>\n\n\n\n

Within that framework, AI becomes an accelerator rather than a creator. It is used to recall the shape of large modern APIs that no individual can reasonably keep in their head, to complete functions based on clearly defined steps, or to generate boilerplate that adds no intellectual value. Such actions are mechanical tasks (something which senior coders will often instruct juniors to do), and offloading these tasks does not weaken the core understanding of the architecture.<\/p>\n\n\n\n

But more crucially, AI-generated code is treated as provisional, not final, and every non-trivial decision is interrogated until it aligns fully with the engineer\u2019s understanding of the system. Functions are not accepted as opaque blocks, but are instead explained, questioned, and, where necessary, rewritten. If the reasoning behind a piece of code cannot be articulated clearly, it does not belong in the system.<\/p>\n\n\n\n

Joint Learning<\/h3>\n\n\n\n

Learning is also a core part of this process, and fundamentally, should be the outcome. As a result of using AI to help accelerate my own coding, I now have a much deeper working knowledge of libraries that I never new existed, small tricks to help made code fast, and can more easily enter new coding spaces that I would otherwise never have the courage to explore.  In this learning process, challenging AI output exposes hidden assumptions, edge cases, and alternative approaches that might otherwise be missed. The interaction between the engineer and AI becomes a form of guided review rather than blind generation, with the engineer retaining responsibility for correctness.<\/p>\n\n\n\n

This also dramatically changes how prompts are used. Instead of asking the AI to create code and moving on, a more natural language conversation first takes place so that both sides fully understand the scope of the situation, while also revealing possible ideas and new concepts. From there, code creation can begin, but the engineer must be able to follow all code, reasoning, and agree with the result. If that agreement cannot be reached, the code is not ready.<\/p>\n\n\n\n

Offloading Repetitive Tasks<\/h3>\n\n\n\n

Repetitive and purely mechanical tasks, however, are easily and intentionally offloaded to AI to preserve human attention for work that actually matters. Creating HTML templates, wiring up standard data structures, or reproducing known patterns adds little value for an experienced engineer and consumes time better spent on system behavior, security, and maintainability.<\/p>\n\n\n\n

When bugs or failures do occur, this approach pays off immediately. Diagnosis is driven by an existing mental model of the system rather than repeated regeneration of code. The engineer should have a reasonable idea of why a failure occurred and either be able to fix it directly or work with the AI to isolate the cause. The goal is understanding, not prompt iteration until the problem disappears.<\/p>\n\n\n\n

Used this way, AI does not replace engineering judgment, but instead, sharpens it dramatically. The model acts as a fast, tireless assistant that accelerates implementation and recall, while responsibility and authority remain firmly with the engineer. Instead of needing to remember how to center a div or create a sort algorithm, engineers spend more time focusing on what truly matters, whether that is overall architecture, system security, or the ability to handle edge cases.<\/p>\n\n\n\n

My Case Study – Custom PHP Framework<\/h2>\n\n\n\n

A practical example of how I use AI to accelerate coding, rather than replace it, comes from a recent project where I built a custom PHP backend framework. This was not an experiment or a toy project, but was a commercial requirement (and still is), where failure was not an option.<\/p>\n\n\n\n

I have built many websites over the years, none of them were particularly elegant, and almost all relied on off-the-shelf tools such as WordPress. Those tools exist for good reasons, but they also come with serious that become difficult to ignore at scale. Large dependency trees, inconsistent performance, a steady stream of security patches, and a surprising amount of resource overhead and bloat for relatively simple requirements.<\/p>\n\n\n\n

In my case, I needed to deploy several sites in parallel; one for myself, two for a client, and another tied to a separate business venture. All of them shared the same core requirements; authentication, content management, private pages, routing, and interactive tools. Now, using a large existing framework (react for example, which I loath for its bloat) would have meant learning and configuring systems that did far more than I needed, while still requiring custom work to make them behave the way I wanted.<\/p>\n\n\n\n

Thus, I decided instead to build a small, focused lightweight PHP framework tailored specifically to these needs. I was not new to PHP or backend development, but this task was different. The framework would be used in a commercial environment, handle user credentials, and expose private files and routes. It had to be predictable, maintainable, and above all else, secure.<\/p>\n\n\n\n

Before writing any meaningful code, I sketched out how the framework should operate, with routing, session handling, access control, error conditions, and edge cases all  being carefully considered upfront. This structure was developed before AI was involved in any meaningful way, and at this point, the implementation was straightforward in many areas. Routing logic, page rendering, and content handling were all well understood problems.<\/p>\n\n\n\n

Security, however, was not.<\/p>\n\n\n\n

That alone was where most of my attention went, and where AI became genuinely useful. But rather than asking ChatGPT to generate a login system or a security layer, I broke the problem down into individual concerns; input handling, session management, database interaction, and file access. Each piece was considered separately, common vulnerability classes were researched, and yes, many long conversations with ChatGPT were had, discussing the many issues to watch out for, functions that might help, and good practice.<\/p>\n\n\n\n

From there, individual functions were defined with clear responsibilities and interfaces, and AI was used to discuss approaches, highlight pitfalls, and review logic, not to invent the code structure. As each component was written, they were individually stress tested and interrogated. Why is this escaped here? What happens if this value is malformed? How does this fail if a request is crafted deliberately?<\/p>\n\n\n\n

And through this process, something more substantial emerged;  what began as scattered security checks evolved into a dedicated security library. Over time, this library grew to handle path validation, request analysis, session integrity, and basic anomaly detection. Not a single function or line of code was opaque, and every function existed for a reason, and each reason was fully understood.<\/p>\n\n\n\n

Instead of creating a mess of vibe code whose meaning is unclear, the result is now a framework that supports routing, shortcodes, controlled access to private resources, and defensive error handling. Adding new functionality is trivial, bugs and errors that do arise are easy to patch, and more importantly, I can open any of the many PHP files, look at a line of code, and know why it\u2019s there.<\/p>\n\n\n\n

Looking at the finished framework, someone could argue that AI played a significant role in its development, and yes, that would be absolutely true. The difference, however, is that I understand the architecture completely. I know why each function exists, how the pieces interact, and how to fix the system when something breaks. I trust it because I can reason about it, not because it appears to work.<\/p>\n\n\n\n

At no point did I ask AI to build me a system. I asked it to help me reason about parts of one.<\/p>\n\n\n\n

Conclusion<\/h2>\n\n\n\n

In my own work, I never trusted AI to independently write code responsible for security, routing, or sanitizing data for database use. Those areas define whether a system is safe or dangerous, and delegating them blindly would have been irresponsible. I needed to understand exactly how and why my framework behaved the way it did, down to individual lines of code and the assumptions behind them.<\/p>\n\n\n\n

Used correctly, AI functioned less like an oracle and more like a team of junior developers handling isolated, well-scoped tasks. Work that would normally consume hours of attention, boilerplate, repeated patterns, solved problems, and mechanical glue code, was reduced to minutes. That time was not saved for its own sake, but reinvested where it actually mattered.<\/p>\n\n\n\n

By offloading low-value work, I was able to focus on security, maintainability, and system behavior. These are the areas where engineering judgment still matters and where mistakes are expensive. AI certainly did not make those decisions for me, but instead, helped to free up enough cognitive bandwidth that I could make them properly.<\/p>\n\n\n\n

The long-term risk of vibe coding is that it does not scale. Systems built without a clear mental model tend to collapse under their own complexity, particularly as teams grow and requirements change. We are already seeing industry concerns around AI-generated codebases becoming harder to reason about and slower to stabilize, especially when responsibility for understanding that code is diffuse. This is not a failure of the tools, but of how they are being used.<\/p>\n\n\n\n

When AI is treated as a helper that accelerates small, well-defined tasks in service of a larger design, it becomes an extremely powerful tool. To me, the parallel with open-source software is obvious; open-source did not eliminate engineers, but amplified them by removing unnecessary reinvention. AI has the potential to do the same, provided authority and responsibility remain human.Some may look at my workflow and label it vibe coding. But as someone who has worked across microcontrollers, microprocessors, backend systems, web platforms, and even custom low-level firmware (including a BIOS), I am comfortable saying otherwise. I know my code. I understand why it exists, how it fails, and how to fix it. That confidence does not come from trusting AI output. It comes from using AI as a tool while keeping engineering judgment exactly where it belongs.<\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Large language models have fundamentally changed how software is written, reviewed, and maintained, often faster than the industry has had time to reflect on the consequences. While AI-assisted coding can dramatically increase productivity, it has also given rise to practices that quietly undermine engineering discipline. One of the most visible is vibe coding<\/strong>, where working output is prioritized over understanding. This article examines why that approach is risky, not because AI is incapable,<\/p>\n","protected":false},"author":71,"featured_media":71631,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,9463],"tags":[9550,9556,9557,9551,9560,9552,9554,7856,9559,9558,9553,9555,8229,9546],"class_list":["post-71633","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ponoko","category-ponoko-originals","tag-ai-coding","tag-ai-assisted-development","tag-backend-development","tag-code-architecture","tag-debugging-practices","tag-developer-productivity","tag-engineering-judgment","tag-large-language-models","tag-maintainable-code","tag-php-framework","tag-programming-with-ai","tag-software-engineering","tag-software-security","tag-vibe-coding"],"yoast_head":"\nHow You Should Code With AI<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"How You Should Code With AI\" \/>\n<meta property=\"og:description\" content=\"Large language models have fundamentally changed how software is written, reviewed, and maintained, often faster than the industry has had time to reflect on the consequences. While AI-assisted coding can dramatically increase productivity, it has also given rise to practices that quietly undermine engineering discipline. One of the most visible is vibe coding, where working output is prioritized over understanding. This article examines why that approach is risky, not because AI is incapable,\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/\" \/>\n<meta property=\"og:site_name\" content=\"Ponoko\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/pages\/Ponoko\/34020780272\" \/>\n<meta property=\"article:published_time\" content=\"2026-02-10T02:19:09+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-02-10T02:20:51+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.ponoko.com\/blog\/wp-content\/uploads\/2026\/02\/10-1.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"800\" \/>\n\t<meta property=\"og:image:height\" content=\"450\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Robin Mitchell\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@Ponoko\" \/>\n<meta name=\"twitter:site\" content=\"@Ponoko\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/\"},\"author\":{\"name\":\"Robin Mitchell\",\"@id\":\"https:\/\/www.ponoko.com\/blog\/#\/schema\/person\/e2e77460b2ec94d57a403675dca3a06a\"},\"headline\":\"How You Should Code With AI\",\"datePublished\":\"2026-02-10T02:19:09+00:00\",\"dateModified\":\"2026-02-10T02:20:51+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/\"},\"wordCount\":3507,\"commentCount\":0,\"image\":{\"@id\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.ponoko.com\/blog\/wp-content\/uploads\/2026\/02\/10-1.jpg\",\"keywords\":[\"AI coding\",\"AI-assisted development\",\"backend development\",\"code architecture\",\"debugging practices\",\"developer productivity\",\"engineering judgment\",\"Large language models\",\"maintainable code\",\"PHP framework\",\"programming with AI\",\"software engineering\",\"Software security\",\"vibe coding\"],\"articleSection\":[\"Ponoko News\",\"Ponoko Originals\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/\",\"url\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/\",\"name\":\"How You Should Code With AI\",\"isPartOf\":{\"@id\":\"https:\/\/www.ponoko.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.ponoko.com\/blog\/wp-content\/uploads\/2026\/02\/10-1.jpg\",\"datePublished\":\"2026-02-10T02:19:09+00:00\",\"dateModified\":\"2026-02-10T02:20:51+00:00\",\"author\":{\"@id\":\"https:\/\/www.ponoko.com\/blog\/#\/schema\/person\/e2e77460b2ec94d57a403675dca3a06a\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#primaryimage\",\"url\":\"https:\/\/www.ponoko.com\/blog\/wp-content\/uploads\/2026\/02\/10-1.jpg\",\"contentUrl\":\"https:\/\/www.ponoko.com\/blog\/wp-content\/uploads\/2026\/02\/10-1.jpg\",\"width\":800,\"height\":450},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.ponoko.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"How You Should Code With AI\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.ponoko.com\/blog\/#website\",\"url\":\"https:\/\/www.ponoko.com\/blog\/\",\"name\":\"Ponoko\",\"description\":\"Laser Cutting & Engraving News For Startup Engineers\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.ponoko.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.ponoko.com\/blog\/#\/schema\/person\/e2e77460b2ec94d57a403675dca3a06a\",\"name\":\"Robin Mitchell\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.ponoko.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/ec42b6c9bb77c45b6adb4d822e74888c895f1251480c2df92a1541b503c11998?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/ec42b6c9bb77c45b6adb4d822e74888c895f1251480c2df92a1541b503c11998?s=96&d=mm&r=g\",\"caption\":\"Robin Mitchell\"},\"url\":\"https:\/\/www.ponoko.com\/blog\/author\/robin-mitchell\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"How You Should Code With AI","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/","og_locale":"en_US","og_type":"article","og_title":"How You Should Code With AI","og_description":"Large language models have fundamentally changed how software is written, reviewed, and maintained, often faster than the industry has had time to reflect on the consequences. While AI-assisted coding can dramatically increase productivity, it has also given rise to practices that quietly undermine engineering discipline. One of the most visible is vibe coding, where working output is prioritized over understanding. This article examines why that approach is risky, not because AI is incapable,","og_url":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/","og_site_name":"Ponoko","article_publisher":"https:\/\/www.facebook.com\/pages\/Ponoko\/34020780272","article_published_time":"2026-02-10T02:19:09+00:00","article_modified_time":"2026-02-10T02:20:51+00:00","og_image":[{"width":800,"height":450,"url":"https:\/\/www.ponoko.com\/blog\/wp-content\/uploads\/2026\/02\/10-1.jpg","type":"image\/jpeg"}],"author":"Robin Mitchell","twitter_card":"summary_large_image","twitter_creator":"@Ponoko","twitter_site":"@Ponoko","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#article","isPartOf":{"@id":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/"},"author":{"name":"Robin Mitchell","@id":"https:\/\/www.ponoko.com\/blog\/#\/schema\/person\/e2e77460b2ec94d57a403675dca3a06a"},"headline":"How You Should Code With AI","datePublished":"2026-02-10T02:19:09+00:00","dateModified":"2026-02-10T02:20:51+00:00","mainEntityOfPage":{"@id":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/"},"wordCount":3507,"commentCount":0,"image":{"@id":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#primaryimage"},"thumbnailUrl":"https:\/\/www.ponoko.com\/blog\/wp-content\/uploads\/2026\/02\/10-1.jpg","keywords":["AI coding","AI-assisted development","backend development","code architecture","debugging practices","developer productivity","engineering judgment","Large language models","maintainable code","PHP framework","programming with AI","software engineering","Software security","vibe coding"],"articleSection":["Ponoko News","Ponoko Originals"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/","url":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/","name":"How You Should Code With AI","isPartOf":{"@id":"https:\/\/www.ponoko.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#primaryimage"},"image":{"@id":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#primaryimage"},"thumbnailUrl":"https:\/\/www.ponoko.com\/blog\/wp-content\/uploads\/2026\/02\/10-1.jpg","datePublished":"2026-02-10T02:19:09+00:00","dateModified":"2026-02-10T02:20:51+00:00","author":{"@id":"https:\/\/www.ponoko.com\/blog\/#\/schema\/person\/e2e77460b2ec94d57a403675dca3a06a"},"breadcrumb":{"@id":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#primaryimage","url":"https:\/\/www.ponoko.com\/blog\/wp-content\/uploads\/2026\/02\/10-1.jpg","contentUrl":"https:\/\/www.ponoko.com\/blog\/wp-content\/uploads\/2026\/02\/10-1.jpg","width":800,"height":450},{"@type":"BreadcrumbList","@id":"https:\/\/www.ponoko.com\/blog\/ponoko\/how-you-should-code-with-ai\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.ponoko.com\/blog\/"},{"@type":"ListItem","position":2,"name":"How You Should Code With AI"}]},{"@type":"WebSite","@id":"https:\/\/www.ponoko.com\/blog\/#website","url":"https:\/\/www.ponoko.com\/blog\/","name":"Ponoko","description":"Laser Cutting & Engraving News For Startup Engineers","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.ponoko.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.ponoko.com\/blog\/#\/schema\/person\/e2e77460b2ec94d57a403675dca3a06a","name":"Robin Mitchell","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.ponoko.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/ec42b6c9bb77c45b6adb4d822e74888c895f1251480c2df92a1541b503c11998?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/ec42b6c9bb77c45b6adb4d822e74888c895f1251480c2df92a1541b503c11998?s=96&d=mm&r=g","caption":"Robin Mitchell"},"url":"https:\/\/www.ponoko.com\/blog\/author\/robin-mitchell\/"}]}},"_links":{"self":[{"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/posts\/71633","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/users\/71"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/comments?post=71633"}],"version-history":[{"count":7,"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/posts\/71633\/revisions"}],"predecessor-version":[{"id":71641,"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/posts\/71633\/revisions\/71641"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/media\/71631"}],"wp:attachment":[{"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/media?parent=71633"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/categories?post=71633"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ponoko.com\/blog\/wp-json\/wp\/v2\/tags?post=71633"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}