Coder Legion - Recent posts tagged code

How to Build an Interactive Web App Without Writing Code

Mon, 12 Oct 2026 08:40:18 +0000

Building a web application no longer requires you to write every line of HTML, CSS, JavaScript, or backend code yourself. No-code development platforms allow users to design interfaces, organize data, configure application logic, and connect services through visual editors.

These tools make it possible for entrepreneurs, small business owners, freelancers, and nontechnical professionals to develop applications that solve practical problems. Examples include appointment booking systems, customer portals, project management dashboards, membership platforms, internal business tools, and online directories.

However, building an interactive application involves more than arranging buttons and choosing colors. A functional app needs a clear purpose, a reliable data structure, rules governing user actions, appropriate access controls, and a way to publish and maintain the finished product.

This guide explains how to build an interactive web app without writing code, from choosing the right platform to testing and launching your application.

Define What Your Web App Will Do
Before opening a no-code builder, establish the problem your application will solve.

A common mistake is starting with the design instead of the function. An attractive interface will not compensate for an application that fails to help users complete their tasks.

Start by answering three questions:

Who will use the application?
What specific problem will it solve?
What should users be able to accomplish inside it?
For example, imagine you want to create an appointment booking application for a small business. Customers should be able to view available services, select a date, submit their contact information, and receive booking confirmation. The business owner should be able to review appointments and manage the schedule.

These requirements establish the essential features before development begins.

Create a short list of functions that the first version must include. For a booking application, that might mean service listings, appointment forms, availability management, booking records, and an administrative dashboard.

Avoid adding every possible feature at the beginning. Build the smallest useful version first, then expand it after testing.

Choose a No-Code Platform
Your platform determines which features you can build, how you manage application data, and how much technical flexibility you have.

Several platforms serve different types of projects.

Bubble
Bubble is worth considering when you need a web application with custom workflows, database operations, conditional logic, and interactive user interfaces. Its visual editor allows users to arrange interface elements and configure actions without manually writing application code.

Bubble's documentation covers interface design, databases, responsive layouts, workflows, and conditional behavior. These capabilities make it relevant to applications that require more than a conventional informational website. Bubble documentation and responsive design guide.

Examples include customer portals, booking systems, membership applications, and business dashboards.

Glide
Glide is useful when your application depends heavily on structured business data. Its platform supports data sources such as Glide Tables, Google Sheets, Excel, Airtable, and supported SQL databases, subject to the relevant plan and configuration requirements.

Its visual development tools let users combine data with interface components and actions. Glide documentation.

This makes Glide worth evaluating for inventory trackers, team directories, operational dashboards, and other applications that display and update organized records.

Webflow
Webflow is particularly relevant when visual website design, content management, and interactive website experiences are central to the project.

Its CMS supports structured, reusable content that can appear across multiple pages. The platform also provides visual site-building and publishing tools. Webflow Help Center.

For projects requiring complex application logic, extensive user-specific data, or advanced account management, assess whether Webflow alone meets the requirements or whether an additional application or integration is necessary.

How to make the choice
Do not select a platform solely because its interface looks easy to use. Check its database capabilities, supported integrations, authentication options, publishing arrangements, usage limits, and total cost.

Build a short prototype before committing to a paid plan. Confirm that the platform can support the functions your project actually needs.

Plan the Application's Pages and Navigation
Once you have selected a platform, map out the pages users will need.

A straightforward application might include:

Home page: Explains the application's purpose and directs visitors to its main functions.
Registration and login pages: Allow users to create accounts and access protected features, when accounts are required.
Dashboard: Displays information relevant to the current user.
Main function page: Provides the application's primary service, such as booking appointments or managing tasks.
Profile or settings page: Allows users to manage permitted account details.
Administrative page: Gives authorized staff access to management functions.
Not every application requires all these pages. A public directory, for example, may not need registration, while a private client portal probably will.

Sketch the navigation before building. Decide where each button leads and which pages require authentication. Keep important actions easy to locate, particularly on mobile screens.

Use consistent typography, spacing, colors, and button styles. A coherent interface makes the application easier to navigate and maintain.

Design the Interface With Visual Components
No-code builders generally provide visual components that can be placed on a page and configured through an editor.

Depending on the platform, these may include text blocks, buttons, forms, images, menus, tables, cards, navigation bars, and reusable containers.

Start with the components required for your core workflow.

For a booking app, you might create a service list, a date selection control, a contact form, a confirmation message, and a page showing existing appointments.

Give each component a clear purpose. A button labeled "Book Appointment" communicates its function more directly than a vague label such as "Continue" when the action creates a booking.

Pay attention to responsive design. Your application should remain usable on desktop computers, tablets, and smartphones. Bubble's responsive design documentation explains how layouts can adapt to different screen sizes within its visual editor. Read the responsive design guide.

Test the layout at several screen widths. Check whether forms remain readable, navigation remains accessible, and buttons are easy to tap.

Create the Database and Organize Your Data
Interactive applications usually need to store information. A booking application needs appointment records, a task manager needs task records, and a customer portal needs customer information.

Your no-code platform may provide a built-in database or allow you to connect an external data source.

Before adding records, identify the information your application must store.

For a booking system, you might need the following data types:

Users: Names, email addresses, and account identifiers.
Services: Service names, descriptions, and durations.
Appointments: Customer references, service references, dates, times, and booking statuses.
Keep related information organized instead of placing every field into one large, unstructured table.

Establish how records relate to one another. An appointment, for example, should reference the customer and service associated with it. This makes it easier to display booking details and manage records consistently.

Use the platform's visual data editor to create fields, configure relationships, and connect page components to the appropriate records.

If you use Glide, its documentation explains how to add and manage supported data sources through the Data Editor. External integrations may have plan requirements and synchronization considerations, so check those details before choosing your data architecture. Glide data source documentation.

Before entering real customer information, establish appropriate access permissions and avoid collecting data that the application does not need.

Add Interactivity With Workflows and Actions
This is the stage that turns a collection of pages into a working application.

An interactive feature responds to a user action. A button might save a record, a form might create an appointment, or a menu might display different content according to the user's permissions.

No-code platforms let you configure many of these behaviors through visual workflows, action settings, and conditional rules.

Consider a task management application. When a user clicks "Add Task," the application should validate the submitted information, save the task, and display the new record in the task list.

A workflow could follow this sequence:

The user opens the task form.
The user enters a task title and due date.
The application checks whether required fields are completed.
The user submits the form.
The application creates a task record.
The task list refreshes or displays the newly created task.
The application confirms that the task was saved.
Bubble documents workflows as sequences of actions triggered by events such as button clicks or page loads. Its visual tools also support conditions that determine how application elements behave. Bubble user manual.

You can apply similar principles to booking confirmations, search filters, account settings, approval processes, and task status updates.

Configure error messages as carefully as successful actions. If a required field is missing, explain what the user must correct. If an operation fails, do not display a success message.

Test each workflow independently before connecting all the features together.

Connect External Services When Necessary
Your application may need services that the no-code platform does not provide directly. Examples include email delivery, payment processing, calendar synchronization, customer relationship management, and external data sources.

Integrations can connect these services without requiring you to build every function yourself.

Start by identifying the exact task that needs an external service. If your booking application must send appointment confirmations, investigate supported email integrations. If it must accept online payments, review compatible payment providers and their requirements.

Check the following before connecting any service:

Whether the integration supports your intended workflow.
Whether it requires a paid subscription or usage-based fees.
What permissions it requests.
Whether it can exchange the necessary data with your application.
How errors and failed transactions are handled.
Some integrations require API credentials or configuration beyond basic drag-and-drop editing. Follow the provider's official documentation and never expose private API keys in publicly accessible page elements.

Add integrations only when they serve a clear purpose. Each additional service introduces another dependency that may require monitoring and maintenance.

Configure User Accounts and Data Security
If your application stores private information or offers different functions to different users, security must be part of the initial design.

Determine which users can view, create, edit, and delete each type of record. A customer should not automatically gain access to another customer's appointments merely because both accounts use the same application.

For example, a booking application might have customer and administrator roles. Customers can view their own bookings, while authorized administrators can manage the overall schedule.

Configure authentication, authorization, database privacy rules, and workflow conditions according to the platform's documentation. Hiding a button from a user is not sufficient protection if the underlying action or data remains accessible through another route.

Bubble's official security documentation explains how privacy rules restrict access to database records and why application builders must configure those protections correctly. Read Bubble's privacy rules guide.

Also consider secure account recovery, access to uploaded files, the handling of personal information, and the removal of access when a user no longer needs it.

If the application handles payments, sensitive customer information, or business-critical records, assess whether you need professional security testing before launch.

Test Every Important Function Before Launch
An application that works in the editor is not necessarily ready for public use.

Testing should cover the complete user journey, not just individual pages. Create test accounts and perform the same tasks that real users will perform.

For a booking application, test whether a customer can select a service, submit a valid appointment, receive the expected confirmation, and view the correct booking record.

Then test failure conditions. Submit an incomplete form, attempt to select an unavailable appointment time, and check what happens when a required integration fails.

Use this practical checklist:

All navigation links lead to the correct destinations.

Forms validate required fields.

Submitted records are saved correctly.

Search and filtering return the intended results.

Buttons trigger the correct actions.

Users cannot access records they are not authorized to view.

Pages remain usable on mobile and desktop screens.

Error messages explain what users should do next.

External integrations work as intended.

The application has been tested with realistic sample data.

Ask a few people who were not involved in building the app to test it. Their difficulties can reveal confusing navigation, unclear instructions, and errors that you overlooked.

Bubble provides a preview environment for testing an application before deployment. Its documentation also explains the distinction between development and live environments. Read the app preview guide.

Publish the App and Monitor Its Performance
When the application passes testing, prepare it for public use.

Review the platform's publishing requirements, domain options, subscription limits, and hosting arrangements. Configure the application's name, branding, and any required account or privacy information.

If you intend to use a custom domain, follow the platform's instructions for connecting it. Confirm that the application loads correctly through its intended public address and that its navigation and integrations continue to work after deployment.

Bubble, for example, documents deployment from its editor and distinguishes the development environment from the live application. Read the publishing guide.

After launch, monitor user feedback, application errors, data quality, and usage limits. Fix defects before adding more features. Keep backups or appropriate recovery arrangements where available, and review access permissions as your user base grows.

You should also review the platform's pricing as usage increases. A prototype with a few test users may have different resource requirements from a production application serving a large customer base. Check current plan terms rather than assuming that an initial free or low-cost arrangement will remain sufficient.

What Are the Limitations of No-Code Development?
No-code tools reduce the need to write application code, but they do not remove every technical constraint.

Complex integrations, unusual business rules, specialized performance requirements, and advanced security needs may require expert assistance or custom development. Some platforms also impose restrictions on integrations, data sources, hosting, or access to application logic.

Platform dependence is another consideration. Before building a business around a no-code application, understand how you can export your data, migrate to another service, maintain integrations, and recover from service interruptions.

You remain responsible for designing the application correctly, protecting user information, complying with applicable requirements, and testing changes before they affect customers.

The right platform is therefore not necessarily the one with the largest feature list. It is the one that can meet your specific requirements within your budget and technical capabilities.

Final Consideration
Building an interactive web app without writing code is a practical option for people who want to turn an idea into a working digital product without developing every component from scratch.

The process starts with a defined problem, followed by platform selection, interface design, database organization, workflow configuration, integrations, security, testing, and deployment.

For applications that require extensive custom workflows and database operations, evaluate Bubble. For data-driven business tools, consider Glide. For visually designed websites with structured content, investigate Webflow and determine whether additional application functionality is necessary.

Start with one useful feature, test it thoroughly, and expand only when the initial version works reliably. A smaller application that performs its intended tasks correctly is a better starting point than a complicated product filled with unfinished functions.

Same Ingress, Different Defaults: What Changed When We Moved to HAProxy

Thu, 08 Oct 2026 08:23:47 +0000

Over the last few weeks, we moved the customer-facing managed services on our NKE service clusters and Deploio from ingress-nginx to HAProxy: Grafana, Loki, ArgoCD, the container registry, Alertmanager, Tempo, OpenSearch, the Object Storage endpoints and all Deploio applications. Some clusters alone had more than 200 Ingresses.

We have written about the motivation twice before. In December, we explained what the retirement of ingress-nginx meant and which migration paths were open. Our TechTalk #29 recap covered our evaluation of Traefik, Gateway API and HAProxy, and why HAProxy became our default for classic Ingress on NKE.

This post is about what happened after that decision.

The annotation mapping table in our documentation gets you a working Ingress on HAProxy in a few minutes. What it does not show is how the defaults shift underneath your workloads. Two ingress controllers can parse the same Ingress resource and still differ in how they talk to your backends, which status codes they send, how long they wait and how many connections they accept before refusing new ones.

We found most of these differences in production, after the switch. One of them broke a customer’s website asset delivery. We are sharing them so you can check your own setup before you migrate.

HTTP to HTTPS Redirects

While comparing responses from both controllers, we noticed that plain HTTP requests were redirected with 302 Found on HAProxy, whereas nginx returned 308 Permanent Redirect.

ingress-nginx sets http-redirect-code to 308 by default. haproxy-ingress defaults its corresponding ssl-redirect-code to a temporary 302. Browsers follow both, but API clients, search crawlers and intermediate caches treat them differently. A 302 allows clients to rewrite a POST into a GET on redirect, whereas a 308 preserves the request method and body.

A silent downgrade to temporary redirects can break API consumers, so we set ssl-redirect-code: "308" globally on our managed controllers to keep the previous behaviour.

Connection Limits

During peak traffic, requests to Deploio applications slowed down and some new connections were refused.

The cause was the connection limit. nginx and HAProxy calculate their ceilings differently:

nginx multiplies worker_processes by worker_connections. With
ingress-nginx setting worker_processes to the node’s CPU count and
worker_connections to 16384, even a modest node can handle tens of
thousands of concurrent connections.
HAProxy enforces a single global maxconn, which haproxy-ingress
exposes as max-connections and sets to 2,000 per pod by default.

Once a pod reaches that ceiling, HAProxy stops accepting new connections. They then queue in the kernel’s accept backlog, which caused the slowdown. Once the backlog is full, they are dropped.

We raised max-connections to 20,000 across all managed controllers.

Timeouts

Shortly after we migrated Deploio, some customers saw requests fail with 504 Gateway Timeout.

haproxy-ingress defaults timeout-client and timeout-server to 50 seconds, while ingress-nginx waits 60 seconds. Ten seconds make no difference for typical web requests, but data exports or reports that reliably finished in 55 seconds suddenly failed with a 504.

To avoid cutting off requests that used to succeed, our managed controllers set both timeout-client and timeout-server to 60 seconds. You can still override the timeout per Ingress with haproxy-ingress.github.io/timeout-server in place of nginx.ingress.kubernetes.io/proxy-read-timeout.

Upstream HTTP Version

In July, we moved an S3-compatible Object Storage endpoint to HAProxy. A customer served website assets through their own nginx reverse proxy in front of that endpoint. Right after the cutover, every asset request failed with 400 Bad Request.

The cause: nginx’s proxy_pass talks to upstreams over HTTP/1.0 by default. ingress-nginx always spoke HTTP/1.1 to backends, regardless of the client’s protocol, and so it silently upgraded the customer’s HTTP/1.0 requests. HAProxy forwards the request with the protocol version the client sent. The Object Storage backend rejected HTTP/1.0 requests, which produced the 400 errors.

The fix was for the customer to add proxy_http_version 1.1 to their reverse proxy configuration:

location / {
    proxy_pass http://storage-endpoint;
    proxy_http_version 1.1;
}

If you run a reverse proxy in front of an NKE or Deploio Ingress, check which HTTP version it sends.

Basic Auth

After we had migrated most managed services, one of the controllers spiked to more than two full CPU cores while serving only 155 concurrent connections. Almost all traffic to that pod hit two endpoints protected by HTTP basic authentication, one of them our metrics ingestion pipeline.

HAProxy verifies basic authentication via crypt(3) synchronously on every request, without caching. A bcrypt hash with a cost factor of 10, the default in most standard libraries and in Helm’s htpasswd template function, takes about 50 ms of CPU time to verify. At 50 ms per check, twenty requests per second are enough to saturate a whole CPU core.

This also applies to nginx, as its auth_basic module verifies every request synchronously and caches nothing either. Because each nginx worker is a single-threaded event loop, a 50 ms verification stalls every connection on that worker. But workers are separate processes, so a controller with eight workers can verify eight passwords in parallel.

HAProxy uses the thread-safe crypt_r(3) only on glibc and FreeBSD. On every other platform, including the Alpine-based image that haproxy-ingress ships, it wraps the plain crypt(3) call in a single process-wide spinlock. Only one thread can verify a password at a time, which caps the whole pod at roughly twenty verifications per second, no matter how many cores it has. And because it is a spinlock, waiting threads do not sleep. They keep their cores busy until it is their turn. That is how a pod serving 155 connections ended up using more than two cores.

The HAProxy manual warns that hashed passwords “can quickly become a major factor in HAProxy’s overall CPU consumption” and notes that musl’s hash implementations are slower than glibc’s. An upstream request to cache successful basic authentication results has been open since 2019 in haproxy/haproxy#370.

For credentials we generate internally, we reduced the bcrypt cost to 4, where verification takes under one millisecond. This is safe because those passwords are long, machine-generated strings of 20 random characters, which makes brute-force attacks computationally infeasible regardless of the cost factor. Helm’s built-in htpasswd function always hashes with bcrypt’s default cost of 10 and offers no way to change it (Sprig source), so chart-generated credentials need to be hashed outside Helm.

The annotation syntax is simpler on HAProxy. Setting haproxy-ingress.github.io/auth-secret alone enables authentication, auth-type is deprecated. The secret format stays the same: an htpasswd file stored under the auth key.

X-Forwarded-For

On paper, this looks like a change in behaviour. In practice it is not one, but it does add a header.

ingress-nginx replaced any incoming X-Forwarded-For with the connecting IP unless the cluster-wide compute-full-forwarded-for option was enabled, and on our shared controllers it was off.

HAProxy’s option forwardfor on its own behaves differently: it appends the connecting IP, so if the client already sent an X-Forwarded-For, the backend receives both. Applications behind a CDN or reverse proxy would then see the whole proxy chain instead of the single value ingress-nginx gave them.

haproxy-ingress closes that gap. Its forwardfor key defaults to add, which deletes any incoming X-Forwarded-For before HAProxy inserts the connecting IP. Your application therefore sees the same as before: a single address, the one that connected directly to the ingress, for example your CDN.

What is new is one extra header. If the request already carried an X-Forwarded-For, haproxy-ingress copies its original value to X-Original-Forwarded-For before discarding it:

X-Forwarded-For: <cdn-or-proxy-ip>
X-Original-Forwarded-For: <whatever-the-client-sent>

On its own, X-Original-Forwarded-For is untrusted input. It is copied verbatim from whoever connected to the ingress, and anyone can put anything into it.

It becomes useful once your application checks who connected. X-Forwarded-For holds the address that opened the TCP connection to HAProxy, which the client cannot forge. If that address belongs to a CDN you trust, for example one of the published edge IPs of your provider, then X-Original-Forwarded-For is the header that CDN sent. Its rightmost entry is the address the CDN saw connecting to it.

HSTS Headers

haproxy-ingress defaults its Strict-Transport-Security header to max-age=15768000 (six months). ingress-nginx sent max-age=31536000 (one year).

RFC 6797 leaves the duration to the operator, and the two projects measure against different yardsticks. Six months is the minimum Qualys SSL Labs has required for an A+ grade since January 2014. HAProxy’s own documentation examples use a value just above it, max-age=16000000, described as “a bit more than 6 months”. When HAProxy published those examples, the HSTS preload list accepted a max-age shorter than one year. It has since raised the minimum to one year.

For standard web traffic, this has no functional impact. If your domain is on the HSTS preload list, however, six months fails validation. We therefore override the haproxy-ingress default and send max-age=31536000 (one year), the same value ingress-nginx did.

If you need a different duration, set spec.forProvider.hsts.maxAge on the IngressHAProxy resource (a duration, for example 8760h). For a single Ingress, set haproxy-ingress.github.io/hsts-max-age (in seconds).

Request Buffering

Under ingress-nginx, high-volume write endpoints produced warnings like this in the controller logs:

[warn] a client request body is buffered to a temporary file /tmp/nginx/client-body/0000000123
  request: "POST /loki/api/v1/push HTTP/1.1"

A while back, one node in our service cluster ran at 98% CPU, with its nginx pod using 1.4 cores mainly to write and clean up temporary disk buffers. On nginx, the fix was to set nginx.ingress.kubernetes.io/proxy-request-buffering: "off" on write-heavy Ingresses such as Loki, Promscale and container registries.

HAProxy streams request bodies to backends by default. There is no equivalent buffering annotation, because HAProxy does not write incoming payloads to disk.

Where This Leaves You

If you still use our managed ingress-nginx on NKE: as announced, support ended on 1 October 2026. HAProxy is available for every NKE cluster, and our migration documentation is the place to start.

If you are unsure how one of these differences affects your workloads, write to us at Emails are not allowed and we will look at it with you.

Framer vs Webflow for Beginners: Which No-Code Builder is Best?

Tue, 06 Oct 2026 05:40:50 +0000

Choosing a website builder is no longer simply a question of finding a platform that lets you publish a page without writing code. Modern no-code builders now combine visual design, content management, hosting, SEO controls, analytics, forms, localization, collaboration, and increasingly, AI-powered tools.

Two platforms that attract a large share of attention in this category are Framer and Webflow. Both allow users to build websites visually, but they approach the process differently. Framer is strongly oriented toward visual design and rapid publishing, while Webflow provides a more extensive system for structured website development, content management, collaboration, and larger projects.

For a beginner deciding between the two, the important question is not which platform has more features. The better question is which platform makes the type of website you want to build easier to create and manage.

Framer and Webflow Take Different Approaches
Framer began with a strong connection to interface and interaction design, and its current website builder continues to emphasize visual creation. Users can build responsive pages on a visual canvas, create CMS-driven pages, manage SEO settings, add forms, use analytics, and publish through Framer's hosting infrastructure.

Webflow also uses a visual development environment, but its system is designed around greater control over website structure, content, interactions, hosting, collaboration, and business requirements. Its CMS is positioned for content-rich websites, while its broader platform includes hosting, localization, SEO, analytics, optimization, and other tools.

That distinction matters for beginners.

If the main goal is to create a polished portfolio, landing page, personal website, agency site, or other design-led project quickly, Framer can be an attractive starting point.

If the goal is to learn a more extensive visual website development system that can accommodate sophisticated CMS structures, larger content operations, localization, and team workflows, Webflow deserves serious consideration.

Which Platform Is Easier for Beginners?
Framer has a strong advantage when simplicity and visual design are the immediate priorities.

Its workflow keeps much of the website creation process inside a visual canvas. Pages can be designed responsively, CMS pages can be generated from collections, and users can manage website content without moving into a completely separate publishing system. Framer's current documentation also describes support for web pages, CMS pages, and design pages.

This makes Framer particularly attractive to someone who thinks visually and wants to see the result while building.

Webflow is also a visual platform, but beginners may encounter more concepts before becoming comfortable. Website structure, classes, responsive behavior, CMS collections, interactions, hosting settings, SEO controls, and other platform functions can require more time to understand.

That is not necessarily a weakness. Greater control can be valuable once a user moves beyond basic websites. The tradeoff is that Webflow can require a larger learning investment.

For someone building their first website, Framer is generally the easier place to begin.

For someone willing to spend more time learning the platform in exchange for deeper control, Webflow can provide a stronger long-term development environment.

Design and Creative Control
This is one of the clearest areas where the platforms differ in practical use.

Framer is built around a design-first workflow. Its visual canvas makes it possible to create responsive pages, navigation, effects, and different breakpoints directly within the design environment.

That approach works especially well for designers, freelancers, creators, startups, portfolio owners, and anyone who wants the website itself to have a strong visual identity.

Webflow also provides extensive visual design control. However, its interface is closely connected to concepts associated with professional web development, including structured styling and reusable systems.

For a beginner, Framer can therefore feel more direct.

For a user who wants to understand how a complex website is constructed and controlled at a deeper level, Webflow may offer more room to grow.

CMS and Content Management
The choice becomes more complicated when content management is a major requirement.

Framer has a CMS that supports collections and dynamic pages. Its official documentation describes CMS pages generated from collection content, with templates that can be used for blog posts, news articles, product pages, case studies, and similar content.

Framer also provides visual content editing and automatic SEO options for CMS pages. Its CMS documentation highlights dynamic titles and descriptions, schema, Open Graph tags, drafts, publishing, and localization capabilities.

Webflow has a more established reputation for structured content management. Its CMS is designed for content-rich websites and allows teams to manage structured content while controlling how that content is presented visually.

For a simple blog or small content site, either platform can work.

For a website expected to contain a substantial amount of structured content, multiple content types, and more complicated publishing requirements, Webflow's broader CMS environment may be more suitable.

SEO: Framer vs Webflow
Both platforms provide built-in SEO controls, meaning users do not have to rely on a separate WordPress-style SEO plugin simply to manage fundamental search settings.

Framer states that its websites are optimized for SEO by default. Its SEO tools include sitemap and robots.txt generation, custom page titles and descriptions, indexing controls, redirects, and structured data options.

Framer also provides built-in analytics and allows integration with Google Analytics.

Webflow provides comparable fundamental SEO controls, including page titles, meta descriptions, URLs, Open Graph settings, and CMS-based SEO fields.

Webflow goes further when localization becomes important. Its Localize system supports localized URLs, metadata, sitemaps, hreflang implementation, and visitor routing.

For a beginner creating a single-language website, neither platform has an obvious fundamental SEO disadvantage.

For larger multilingual websites, Webflow offers a more extensive localization system.

Forms and Analytics
A modern business website needs more than attractive pages. It also needs a way to collect leads and measure visitor activity.

Framer includes native forms and built-in analytics. Its documentation covers contact forms for leads, bookings, signups, and inquiries, as well as spam protection and analytics.

Framer also allows users to assign tracking IDs to links and forms and view those events through Analytics Overview. The platform supports funnels and A/B testing as part of its analytics and testing capabilities.

Webflow provides forms and a broader set of marketing and optimization tools within its platform. Its current platform includes Analyze and Optimize products, while its paid Site plans include different levels of functionality depending on the selected plan.

For a small website, Framer's built-in tools may be enough.

For a company that expects website analytics, optimization, localization, collaboration, and other marketing functions to become increasingly important, Webflow's broader platform can be more compelling.

Pricing Matters for Beginners
Pricing can change, so it is important to compare current plans rather than rely on old articles.

As of October 2026, Framer lists a free plan, Basic at $10 per month, and Pro at $30 per month, with annual billing displayed on its pricing page. The Basic plan includes a custom domain, two CMS collections, 50 GB of bandwidth, and built-in SEO. The Pro plan increases the CMS collections limit to 10 and includes features such as redirects, staging, and branching with previews.

Webflow currently offers a free Starter plan. Its Basic Site plan is listed at $15 per month when billed yearly, while its Premium plan is listed at $25 per month when billed yearly. The Premium plan includes Webflow CMS, while the Basic plan is intended for simpler websites without CMS requirements.

Webflow also separates Site plans from Workspace plans, which means users need to understand the distinction between hosting a website and managing projects, staging environments, collaboration, and related Workspace functions.

For a beginner comparing only the entry-level paid plans, Framer currently has the lower listed starting price.

However, price alone should not determine the decision. A cheaper plan that lacks a feature you later require can become more expensive if it forces a move to another tier or platform.

Localization and International Websites
International websites introduce another important difference.

Framer supports localization and provides tools for translating and adapting sites. Its current platform documentation also describes localization as part of its broader website-building system.

Webflow has invested heavily in localization. Webflow Localize supports multiple locales, localized content and styles, localized page settings, SEO metadata, URLs, and sitemap functionality.

Webflow's localization system can therefore become particularly relevant to companies operating across different countries or language markets.

A beginner building a personal portfolio probably does not need to prioritize this feature.

A business planning a multilingual website should examine it carefully before choosing a platform.

Collaboration and Growing Teams
The platform choice can change when a solo website becomes a team project.

Framer introduced a new billing system in 2026 that includes different editor types, including Content Editors for people who manage CMS content without requiring full editing access.

Webflow has a broader Workspace system with collaboration features, staging environments, seats, permissions, publishing workflows, and team-oriented plans. Its current Team plan is designed for growing organizations and includes features such as Localize, publishing workflows, page branching, single-page publishing, and additional governance capabilities.

For a solo creator, these differences may not matter much.

For agencies, marketing departments, and organizations with multiple people involved in website production, Webflow's collaboration architecture deserves close attention.

Which One Is Better for a Portfolio?
For a personal portfolio, designer portfolio, freelancer website, or creative landing page, Framer is a strong choice.

The visual workflow allows beginners to concentrate heavily on the appearance and presentation of the website. Its hosting, CMS, SEO, analytics, and publishing functions are integrated into the same platform.

Webflow can also produce excellent portfolios, but it may introduce more concepts than a beginner needs for a relatively small project.

If the objective is to launch a visually impressive portfolio without spending weeks learning a complex platform, Framer is the more straightforward recommendation.

Which One Is Better for a Business Website?
The answer depends on the business.

A small company that needs a professional homepage, services page, contact page, and a few supporting pages can use either platform successfully.

Webflow becomes more attractive when the website requires a structured CMS, multiple content types, localization, advanced collaboration, extensive marketing operations, or a larger team.

Framer remains a strong choice when visual design, rapid publishing, and ease of use are the highest priorities.

Which One Is Better for a Blog?
Both platforms can support blogs through their CMS systems.

Framer's CMS can generate dynamic pages from collections, making it possible to create blog posts and other recurring content from reusable templates.

Webflow's CMS is also designed for structured content and content-rich websites.

For a small independent blog, either platform can work.

For a publication that expects complicated content structures, larger editorial operations, multiple content types, or more advanced team workflows, Webflow is likely the stronger candidate.

Framer vs Webflow: The Beginner's Verdict
There is no universal winner because the platforms prioritize different aspects of website building.

Framer is the better choice for beginners who want:

A highly visual website-building workflow
Fast project creation
Design-focused websites
Portfolio websites
Landing pages
Small business websites
Straightforward CMS projects
Built-in SEO and analytics tools
A lower starting price for paid plans
Webflow is the better choice for beginners who want:

A deeper website development environment
More extensive CMS capabilities
Content-heavy websites
Larger business websites
Advanced collaboration
Multilingual and international websites
More extensive marketing and optimization capabilities
A platform that can accommodate increasingly complex projects
The important point is that Webflow is not automatically better because it has more features, and Framer is not automatically better because it is easier to approach.

For a first website, Framer is probably the better starting point for most beginners who prioritize simplicity and visual design.

For someone who intends to build more complex websites and is prepared to spend more time learning the platform, Webflow is the stronger long-term candidate.

The best choice is therefore determined by the website being built, not by which platform has the longer feature list.

Before committing to either service, beginners should also check the current pricing and feature limits. Both companies continue to update their products and plans, and Webflow made significant pricing and plan changes during 2026.

If the goal is to get a polished website online quickly, start with Framer.

If the goal is to develop deeper skills for building structured, content-rich, collaborative websites, start with Webflow.

For most first-time users, that distinction is more useful than simply asking which platform is "best."

How to Make Your Website Cookie Compliant (GDPR and CCPA Tools)

Mon, 21 Sep 2026 11:12:09 +0000

A website can load dozens of cookies, tracking scripts, pixels, tags, local storage objects, and third-party services without the site owner realizing exactly what is running.

Google Analytics, advertising platforms, embedded videos, social media widgets, payment systems, chat tools, security services, and marketing platforms can all introduce technologies that store or access information on a visitor's device.

That creates a compliance problem.

Cookie compliance is not simply about displaying a pop-up that says, "We use cookies." For websites serving visitors in the European Economic Area, the United Kingdom, California, and other jurisdictions with privacy requirements, the website needs to identify its tracking technologies, explain their purposes, obtain consent where required, respect opt-out choices, and maintain appropriate records.

The exact requirements depend on the visitor, the technology being used, the purpose of processing, and the laws that apply to the website.

Here is how to build a practical cookie compliance system.

Start With a Cookie and Tracker Audit
Before installing a cookie banner, find out what your website actually uses.

A typical website may have:

Essential cookies for authentication or security
Preference cookies
Analytics cookies
Advertising cookies
Social media trackers
Tracking pixels
Embedded third-party content
Marketing and conversion tags
Local storage and other device-access technologies
The important point is that compliance is not limited to traditional cookies. The UK Information Commissioner's Office, for example, treats cookies, tracking pixels, web storage, fingerprinting, scripts, tags, and similar technologies as storage and access technologies.

Run a scan of the website and create an inventory containing the technology name, provider, purpose, category, duration, and whether it is first-party or third-party.

Do this before configuring the consent banner.

Otherwise, you may create a polished banner while unknown scripts continue operating underneath it.

Separate Essential and Non-Essential Technologies
The next step is classification.

Some technologies are necessary for the website to provide a service requested by the visitor. Examples can include authentication or maintaining an online shopping basket.

Other technologies exist primarily for analytics, advertising, personalization, or tracking.

The distinction matters because certain essential technologies may qualify for an exemption from consent requirements, while non-essential technologies generally require consent under applicable cookie rules.

The ICO states that websites must obtain consent for non-exempt storage and access technologies and must not pre-enable them before consent.

The European Commission also distinguishes operational cookies from analytics and third-party cookies on its own websites. Its cookie policy states that certain authentication and technical cookies are necessary for website operation, while visitors can refuse analytics cookies.

Do not automatically classify every first-party cookie as essential. Classification should be based on what the technology actually does.

Build a Proper Consent Banner
A compliant consent banner needs to give visitors meaningful control.

For GDPR-related consent, the European Commission states that consent must be freely given, specific, informed, and unambiguous. The request should clearly explain what the visitor is agreeing to and allow consent to be withdrawn.

The European Data Protection Board has also published detailed guidance on the requirements for valid consent under the GDPR.

A practical banner should therefore identify the main purposes of non-essential tracking and provide controls for accepting or refusing those purposes.

For example, categories can include:

Necessary: Required for website operation.
Preferences: Used to remember visitor settings.
Analytics: Used to measure website usage.
Marketing: Used for advertising, retargeting, or related marketing purposes.
The visitor should not have to accept analytics or advertising technologies simply to access the website.

The ICO specifically states that merely continuing to browse a website does not constitute valid consent for non-essential cookies.

Do Not Load Tracking Scripts Before Consent
This is one of the most important technical steps.

A consent banner is not enough if Google Analytics, advertising pixels, or other non-essential trackers have already loaded before the visitor makes a choice.

The consent management platform should control the scripts themselves.

For example, a visitor who rejects marketing cookies should not subsequently receive advertising trackers merely because the banner was displayed.

The ICO states that non-exempt storage and access technologies must not be pre-enabled before consent.

This means your implementation needs to connect the consent system to Google Tag Manager, analytics tools, advertising scripts, embedded content, and other relevant third-party services.

Test this with browser developer tools rather than assuming the configuration works.

Give Visitors a Way to Change Their Choice
Cookie consent should not be a one-time decision with no practical way to change it.

Your website should provide a visible mechanism for reopening the privacy preferences panel.

This can be a persistent "Cookie Settings," "Privacy Settings," or similar control in the footer.

The ICO recommends making it easy for users to enable or disable non-essential technologies and says consent should be specific to the purposes involved.

Your system should therefore support both initial consent and later withdrawal.

If a visitor originally accepts analytics cookies and later withdraws that permission, the website should honor the new preference.

Understand the CCPA Difference
GDPR and CCPA should not be treated as identical cookie laws.

California's privacy framework gives consumers rights concerning their personal information, including rights to opt out of the sale or sharing of personal information. The California Attorney General states that businesses subject to these requirements must provide appropriate methods for consumers to submit opt-out requests.

California also recognizes user-enabled opt-out preference signals, including Global Privacy Control (GPC), for applicable opt-out requests.

The California Privacy Protection Agency's regulations effective January 1, 2026, clarify that a cookie banner by itself is not an acceptable method for submitting a request to opt out of the sale or sharing of personal information.

That distinction matters.

A website may need both a cookie preference mechanism and a separate California privacy control, such as an appropriate "Do Not Sell or Share My Personal Information" or "Your Privacy Choices" mechanism, depending on its obligations.

Use a Consent Management Platform
For a small website, manually managing dozens of scripts can become difficult.

A Consent Management Platform, or CMP, can automate several parts of the process.

Common features include:

Cookie and tracker scanning
Cookie categorization
Consent banners
Preference centers
Regional rules
Script blocking
Consent records
Cookie policy generation
Third-party integrations
Privacy request tools
Several commercial platforms offer these functions.

OneTrust provides cookie scanning, tracker categorization, customizable consent banners, regional configuration, automated blocking, scheduled scanning, and consent records.

Termly provides a cookie consent manager covering GDPR, ePrivacy, CCPA, and other privacy frameworks. Its platform includes consent banners, automatic cookie policy generation, consent logs, and tools for privacy requests and "Do Not Sell or Share" links.

Complianz is particularly relevant to WordPress websites. Its plugin provides cookie scanning, consent management, script and iframe blocking, consent records, regional configurations, and integrations with third-party services.

These tools can reduce implementation work, but installing one does not automatically make a website legally compliant. Configuration still has to match the website's actual technologies, data practices, visitors, and applicable laws.

Keep Your Cookie Policy Accurate
Your cookie policy should match what is actually operating on the website.

At minimum, the policy should explain the types of cookies or similar technologies being used, their purposes, relevant providers, and applicable retention periods where required.

Do not publish a generic cookie list and assume the job is finished.

If you install a new advertising platform, analytics service, chatbot, embedded video service, or marketing tool, scan the website again and update the relevant disclosures.

The European Commission's own cookie policy demonstrates this approach by listing individual cookies, their services, purposes, types, and durations.

Test the Website Before Going Live
Cookie compliance should be tested technically.

Open the website in a fresh browser session and inspect what happens before making a consent decision.

Check whether:

Non-essential cookies load before consent.
Advertising scripts execute before consent.
Analytics technologies activate before permission.
Rejecting optional cookies actually prevents their activation.
Embedded third-party content bypasses the consent mechanism.
Changing preferences later is respected.
Consent records are generated where required.
California opt-out signals are handled where applicable.
Repeat the test after installing plugins, changing tag-manager configurations, adding advertising tools, or redesigning the website.

A cookie audit is not a one-time project. Websites change continuously.

Treat Compliance as an Ongoing Process
The biggest mistake is treating cookie compliance as a banner installation task.

Websites evolve.

A marketing employee can install a new tracking pixel. A developer can add a new analytics service. A WordPress plugin can introduce another third-party script. A redesign can add embedded content from an external provider.

Each change can affect the site's privacy obligations.

The ICO recommends considering storage and access technologies during the design and implementation of online services and maintaining appropriate arrangements with third parties.

For that reason, schedule regular scans and review the results.

A practical process is:
Audit: Identify cookies, scripts, pixels, tags, and other technologies.

Classify: Determine which technologies are necessary and which require permission or other controls.

Configure: Connect the CMP to the website's scripts and third-party services.

Disclose: Maintain accurate cookie and privacy documentation.

Test: Verify the website's behavior before and after each consent choice.

Monitor: Rescan the website whenever technologies or vendors change.

Before calling a website cookie-compliant, verify that you have:

Audited cookies and similar tracking technologies.
Identified third-party services.
Classified technologies according to their purpose.
Prevented applicable non-essential technologies from running before consent.
Created a clear consent mechanism.
Provided granular choices where required.
Made refusal reasonably accessible.
Provided a method for withdrawing or changing consent.
Published accurate cookie information.
Implemented applicable California opt-out mechanisms.
Considered Global Privacy Control where applicable.
Maintained consent records where required.
Tested the website technically.
Established a process for future cookie and tracker changes.
The objective is not simply to put a cookie banner on the homepage. A properly implemented system connects the banner, tracking technologies, privacy documentation, consent records, and user controls.

For websites operating across multiple jurisdictions, the requirements can differ substantially. GDPR, UK rules, and California privacy requirements should therefore be assessed according to the actual visitors, services, technologies, and data practices involved. A CMP can automate much of the technical work, but it cannot replace proper configuration and legal review.

Manage Your Infrastructure at Nine in Code

Mon, 14 Sep 2026 04:44:42 +0000

If you’ve ever managed infrastructure through a web interface, you know how easy it is to lose track of which settings you changed, when, and why. It’s convenient in the moment, but difficult to reproduce, review, or automate later. Especially when multiple people work on the same infrastructure.

That’s where Infrastructure as Code (IaC) comes in. Instead of describing your infrastructure through clicks in a UI, you describe it in code. That code can be version controlled, reviewed through pull requests, reused, and executed repeatedly to produce the same result every time.

Infrastructure as Code is just a part of the picture. Modern platforms are also driven by APIs, command-line tools, deployment platforms, configuration management, and GitOps workflows. Together, these tools make it possible to interact with and automate your infrastructure entirely through code.

This is especially valuable if you’re building a platform for other teams to use. Standardizing how infrastructure is provisioned, whether through Terraform modules, Ansible playbooks, or GitOps repositories, gives every team a consistent, reviewable way to work instead of each team inventing its own approach. It also makes it much easier to see where infrastructure costs actually come from, since resources tied to a specific team or project are defined explicitly in code rather than scattered across a shared account.

Whatever your preferred workflow, there’s a good chance we already have a tool, example, or guide to help you get started.

Your toolkit for interacting with us through code

Tool / What it does / Best for
Nine API / Direct REST access to all Nine resources / Custom integrations, your own tooling
nctl/ CLI built on the Nine API / Day-to-day operations, scripting, CI/CD
Deploio / Managed application platform (git push to deploy) / Deploying applications without managing infrastructure
Terraform / Declarative provisioning of cloud resources / Versioned, reviewable environments (clusters, databases, storage)
Ansible / Orchestration of multi-step workflows / Provisioning, configuring, and validating in one playbook
ArgoCD / GitOps continuous delivery for Kubernetes / Keeping deployed applications in sync with a Git repository

The Nine API

The Nine APIs are the foundation of automation on our platform. They expose all our public services through a REST API based on Kubernetes concepts, making them familiar to anyone already working with cloud native tooling.

You can interact with the API using:

curl
kubectl
or your own applications and automation.

If none of the existing tools fit your workflow, you can build your own. The API is open, standards based, and designed to be integrated into your own scripts, applications, or internal platforms.

Full documentation is available at docs.nine.ch/api.

To learn more about the ideas behind the API, read our blog post Introducing the Nine Self-Service API.

nctl: The Nine Command Line Interface

nctl is our command line client built on top of the Nine API. It provides a convenient interface for creating, updating, and inspecting your Nine resources directly from the terminal, without having to use HTTP requests or Kubernetes manifests yourself.

It’s a great choice if you want to automate repetitive tasks, integrate us into shell scripts or CI/CD pipelines, or simply prefer working from the command line. Behind the scenes, nctl uses the same public API, so anything you learn with nctl also helps you understand the underlying platform.

The nctl documentation contains installation instructions, getting started guides, and examples for working with Kubernetes clusters, databases, object storage, virtual machines, Deploio applications, and many other Nine services.

Deploio

Deploio is our managed application platform. Instead of provisioning infrastructure yourself, you simply point Deploio at your Git repository. It clones your source code, builds it into an OCI container image, deploys a new release, and exposes your application automatically.

Out of the box, Deploio supports several popular languages and frameworks through Cloud Native Buildpacks. If your application requires more control, you can also build it using your own Dockerfile, making it possible to run virtually any web application.

Although the platform hides much of the operational complexity, it doesn’t turn deployment into a black box. Using nctl you can inspect build and release logs, retry failed builds or releases, execute a shell inside a running application, or even pull the generated OCI image to your local machine for debugging.

Browse our Deploio examples repository, which contains sample applications for different languages and frameworks. If your favorite technology is missing, let us know - we’re always happy to expand our examples.

You can also learn more in our blog:

Using Git to Release and Run Your Web App on Deploio
Why We Added Dockerfile Support to Deploio

Terraform: classic Infrastructure as Code

If you’re already comfortable managing individual resources with nctl or the API directly, you might wonder when Terraform makes more sense. nctl and the API are ideal for quick, imperative changes, scripting, and day-to-day operations. Terraform is the better fit once you need to provision and version an entire environment declaratively, for example a Kubernetes cluster together with its databases and storage buckets as a single reviewable, repeatable unit, especially when that state needs to be shared and reviewed across a team.

Terraform is a popular Infrastructure as Code tool for provisioning cloud resources. Instead of creating infrastructure manually, you describe the desired state in code and let Terraform determine which resources need to be created, updated, or removed.

This makes it easy to version your infrastructure, review changes through pull requests, and recreate identical environments whenever needed. Terraform is an excellent choice for provisioning long lived infrastructure such as Kubernetes clusters before handing them over to application deployment tools like ArgoCD.

Our Terraform examples show how to provision Nine resources entirely through code and can serve as a starting point for your own infrastructure.

Ansible: automating infrastructure setup

While Terraform focuses on provisioning infrastructure, Ansible excels at orchestrating complete workflows. Using simple, human readable YAML playbooks, you can provision resources, wait for them to become available, retrieve connection details, configure services, validate the deployment, and automate any follow-up tasks.

Our guide From Zero to Infra: Building a Production-Ready Setup Using Our API & Ansible demonstrates how to combine Ansible with the Nine API and nctl to provision a production like environment consisting of a PostgreSQL database, a Redis instance, and a virtual machine. Along the way, the playbooks also retrieve connection information and verify that each service is ready to use.

ArgoCD: Continuous Delivery the GitOps way

ArgoCD brings the GitOps approach to Kubernetes. Instead of deploying applications manually, you store your Kubernetes manifests or Helm charts in a Git repository. ArgoCD continuously monitors that repository and ensures that your cluster always matches the desired state defined in Git.

This means every deployment is version controlled, reviewed through pull requests, and easy to roll back if necessary. If someone makes a manual change to the cluster, ArgoCD detects the drift and can automatically reconcile it, keeping your applications in the state you’ve declared.

Our ArgoCD example applications demonstrate how to deploy applications on Nine using Helm and GitOps workflows. Feel free to use them as a starting point for your own projects.

To see this in practice, read how we helped mühlemann+popp introduce ArgoCD to give their healthcare customer full visibility into deployments while migrating to Nine Kubernetes Engine.

Explore, Contribute and Improve

All our open source projects are available on our GitHub

Browse the repositories, fork them, submit pull requests, or simply use them as inspiration for your own projects. We always welcome feedback and contributions.

Join the Conversation

Is there a tool, example, or integration you’d like to see? Open an issue on the relevant GitHub repository and tell us what’s missing or unclear. We’d love to hear how you’re managing your infrastructure at Nine in code.

The Unseen Intuition: Decentralization, Human Prompting, and the Art of Readable Code

Sun, 09 Aug 2026 04:52:59 +0000

Open source software was built to defragment monoliths, serving as the ultimate catalyst for developer productivity and collective innovation. Ostensibly, many open source ecosystems face a subtle paradox: governance models that quietly centralize motives. When legacy stewards hold weighted influence — the open-minded spirit shifts. True evolution relies on distributed momentum, not administrative inertia. Sustainable growth requires dynamic environments where updates happen fluidly, every contributor’s voice carrying input.

As software development rapidly integrates AI and Agentic systems, speed increases exponentially. But machine efficiency alone misses a vital layer: human context. While AI generates vast architectures in seconds, human intuition provides the nuanced vision behind it — a reality reflected in the prompts humans craft. Whether guiding media generation, writing complex logic, or refining copy, a prompt reveals how an individual perceives, abstracts, and solves a problem.

To bridge this gap, human developers who take the lead in documenting processes directly within the code enhance output. Elevating readability through explicit annotations — / tips, hints, and tricks / — is not just about standard documentation; it is about preserving individual intuition. Lines of code should be an open map, readily deciphered and freely tailored. Because at its core, code is fluid art: anything and everything can be customized, repurposed, and reshaped.

Preserving open source optimistically requires protecting creative independence, decentralization, and ensuring human perspective remains legible within an automated world.

Book Your Movie Tickets with Python

Sun, 12 Jul 2026 07:55:51 +0000

My simple Python Movie Ticket Booking Calculator that helps users simulate booking a ticket by changing ticket types , prices and more and then calculating the total cost in a clear and easy way

The Movie Ticket Booking Calculator

base_price = 15 # Place Holder
age = 21 # Place Holder
seat_type = "Gold" # Place Holder
show_time = "Evening" # Place Holder

if age > 17:
    print("User is eligible to book a ticket")

if age >= 21:
    print("User is eligible for Evening shows")
else:
    print("User is not eligible for Evening shows")

is_member = False # Place Holder
is_weekend = False # Place Holder

discount = 0
if is_member and age >= 21:
    discount = 3
    print("User qualifies for membership discount")
else:
    print("User does not qualify for membership discount")
print(f"Discount: ${discount}")

extra_charges = 0
if is_weekend or show_time == "Evening":
    extra_charges = 2
    print("Extra charges will be applied")
else:
    print("No extra charges will be applied")
print(f"Extra charges: ${extra_charges}")

if age >= 21 or age >= 18 and (show_time != "Evening" or is_member):
    print("Ticket booking condition satisfied")

    service_charges = 0
    if seat_type == "Premium":
        service_charges = 5
        print(f"Service charges: ${service_charges}")
    elif seat_type == "Gold" :
        service_charges = 3
        print(f"Service charges: ${service_charges}")
    else:
        service_charges = 1
        print(f"Service charges: ${service_charges}")
    final_price = extra_charges + service_charges + base_price - discount
    print(f"Final price of ticket: ${final_price}")
else:
    print("Ticket booking failed due to restrictions")

Features

Checks if the user is eligible to book a movie ticket
Adds extra charges for evening shows or weekend bookings
Applies a membership discount only when the user qualifies
Supports different seat types
Uses clear conditional logic with if , elif, and else statements

What Is SARIF and How Does It Help Security Tools Work Together?

Sat, 04 Jul 2026 16:06:30 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.

If you've ever worked with tools like Semgrep, Trivy, Checkov, Gitleaks, or CodeQL, you've probably noticed that each tool produces results in a different format. Some output JSON, some use XML, while others generate plain text reports.

This creates a problem: how do you aggregate multiple tools results from multiple tools into a single platform?

That's where SARIF comes in.

What is SARIF?

SARIF stands for Static Analysis Results Interchange Format.

It is an open standard designed to represent findings from static analysis tools, security scanners, linters, and code quality tools in a common format.

Think of SARIF as a universal translator.

Instead of every tool speaking its own language:

Semgrep -> Semgrep JSON
Trivy -> Trivy JSON
Checkov -> Checkov JSON
Gitleaks -> Gitleaks JSON

SARIF allows all of them to communicate using a shared structure:

Semgrep
Trivy
Checkov
Gitleaks
    ↓
   SARIF

Why Was SARIF Created?

Imagine a company running 20 different scanners in its CI/CD pipeline.

Each scanner reports:

Different severity levels
Different file formats
Different metadata
Different output structures
Different CVE
Different CVSS scores

Building integrations for every tool becomes difficult and expensive.

SARIF solves this problem by providing a standardized schema for:

Rule IDs
Messages
Severity
File locations
Code snippets
Security metadata
Fix suggestions

This allows platforms to consume results from many tools without writing custom integrations for each one.

A Simple Example

Suppose a security scanner finds a vulnerability:

File: app.py
Line: 42
Severity: High
Message: Possible SQL Injection

In SARIF, that information becomes structured JSON that any compatible platform can understand.

The scanner changes, but the format remains the same.

How SARIF Helps Developers

One Format for Many Tools

Instead of handling dozens of output formats:

Tool A -> Format A
Tool B -> Format B
Tool C -> Format C

you can standardize on:

Tool A
Tool B
Tool C
   ↓
 SARIF

Better Tool Interoperability

A SARIF file generated by one tool can be consumed by another platform without modification.

This makes integrations significantly easier.

GitHub Code Scanning Support

One of the biggest reasons SARIF became popular is GitHub Code Scanning.

GitHub accepts SARIF uploads and automatically displays:

Security findings
Code quality issues
Vulnerabilities
File-level annotations

directly inside pull requests and repositories.

Easier Aggregation

Organizations often run multiple scanners:

Semgrep
Trivy
Checkov
Gitleaks
Bandit

SARIF makes it possible to combine all findings into a single report.

Conclusion

SARIF is a common language that allows tools to exchange findings in a standard way.

As the number of security and code analysis tools continues to grow, standards like SARIF help reduce integration complexity and make tool ecosystems work together more effectively.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub

CodeMender IA — Universal Cloud Architect for VS Code

Wed, 10 Jun 2026 16:50:39 +0000

Stop Fixing Syntax. Start Architecting Solutions.

For software developers, full-stack engineers, and cloud architects, standard linters are no longer enough. Standard linters only tell you where a syntax error is; they don't tell you why your software architecture will fail under production-level scale.

To solve this gap, we built CodeMender IA—the first "Bring Your Own Model" (BYOM) DevOps Intelligence Engine designed directly for Visual Studio Code. It acts as a virtual Senior Software Architect sitting inside your editor, providing real-time analysis of logical fallacies, technical debt, and cloud scalability.

Key Technical Capabilities:

🔌 Universal API Support (BYOM): You are completely free from vendor lock-in. Connect CodeMender IA to your preferred model, including Google Gemini (fast/free tiers), OpenAI (GPT-4o), Anthropic (Claude 3.5 Sonnet), or run local offline models (Ollama/DeepSeek) for 100% data privacy.
☁️ Cloud Native Auditing: Instantly scan your codebase for Kubernetes and cloud readiness, verifying 12-Factor App compliance, statelessness violations, and hardcoded env secrets.
📊 Technical Debt Calculator: Analyze your logical complexity before compiling. CodeMender IA identifies inefficient algorithms (such as nested loops with O(n^2) time complexity) and estimates CPU/RAM usage spikes on serverless environments like AWS Lambda and Azure Functions.
🗺️ Scalability Heatmaps & Migration Paths: Visualize which parts of your workspace are monolithic versus modular, and get step-by-step refactoring recommendations to transition complex functions into clean, independent microservices.

Eliminate syntax bottlenecks, reduce cloud architecture overhead, and future-proof your codebase natively from your editor.

👉 Install CodeMender IA directly from the Visual Studio Marketplace:
https://marketplace.visualstudio.com/items?itemName=SEOSiri.codemender-ia

How I Review PRs with AI — Without Losing My Own Judgment

Sun, 26 Apr 2026 14:07:05 +0000

Originally published on Medium:
https://medium.com/@rajkundalia/how-i-review-prs-with-ai-without-losing-my-own-judgment-f930ad30dc60

Over the last few months, my code review queue has changed completely. With agentic coding, PRs are larger, faster, and harder to reason about.

I needed a system that was faster, but I absolutely did not want to just hand things off to an AI and call it a review.

Built-in tools exist. Claude Code has /review or /deep-review, and GitHub Copilot's PR review is decent out of the box. If you just want an AI pass, they work fine. But I am not optimizing for just an AI pass; I am optimizing for understanding and architectural signal.

Here is a repeatable framework I use to let AI handle the heavy scanning, while I keep the heavy thinking and judgment firmly in my own hands.

(Note: All the prompts referenced below are open-source in my GitHub repo: https://github.com/rajkundalia/ai-code-review-prompts. They are tool-agnostic — paste them into Claude, ChatGPT, Cursor, or whatever you prefer.)

The Golden Rule: Context Isolation

Before we get into the phases, there is one non-negotiable rule that makes this entire system work: One AI session per PR.

If you mix your own daily work, multiple PR reviews, and random questions into a single AI session, you lose context. PR reviews are context-heavy. When a colleague replies to your comment four days later, having a dedicated, preserved AI session helps you instantly remember your mental model and why you left that comment in the first place.

Keep the thread alive from the start of the review through the merge.

The 4-Phase PR Review Workflow

When I load my initial prompt, it gives me a starting point: a high-level summary, the files touched, and the core intent of the PR. From there, I move through four distinct phases. Do not skip ahead.

Phase 1: Build Understanding (Human First)

What happens next is entirely mine. I go file by file, line by line, and ask the AI questions until I have built my own understanding of the flow:

What is this doing?
Where is this data model used further downstream?
What breaks if this assumption changes?

This is deliberately manual. Anything I still do not understand after interrogating the AI, I flag for a human comment.

If you skip this phase, you're not reviewing the code — you're reviewing the AI's opinion of the code.

Phase 2: AI First Pass (Filter the Noise)

This is where the AI does its first real pass, flagging standard issues and inconsistencies. This is intentionally a surface pass.

The reason this is a separate phase from the deep review is simple: I want the obvious stuff caught and out of the way early. It gives me a chance to dismiss irrelevant suggestions immediately, ensuring the next phase isn't cluttered with noise.

Think of this as signal extraction, not decision-making.

Phase 3: The Deep Review (Pressure Testing)

This is the heaviest phase, driven by a few specific forcing functions:

The "Chief Programmer" & "Chief Architect" Persona
Giving the AI a specific role produces sharper, more critical output than a generic "review this code." You can adjust the role to fit your domain, e.g., chief AI engineer if you are reviewing prompt code.

Real Coverage vs. Theater
AI agents generate a massive amount of tests. Left unchecked, they will write tests for data models with no logic, or tests that just verify Python works. I explicitly prompt the AI to look for meaningful behavior validation so we catch the noise upfront. It is better than constantly asking the AI to remove redundant tests.

Tests should prove behavior, not existence.

Playing Devil’s Advocate
I force the LLM to question its own assumptions. What could go wrong? Where would this fail in production three months from now?

This surfaces edge cases that standard reviews easily miss.

Phase 4: The Verdict

Finally, I combine my Phase 1 understanding with the AI's deep review insights. The AI helps me classify the findings into:

Must-fix blockers
Good-to-have stylistic suggestions
Noise to be discarded

The Author's Duty: Self-Review

Before your code ever reaches another human, it is your responsibility to review it.

I converted my PR review framework into a self-review prompt. I run through the exact same phases on my own code. The output here is highly surgical: it tells me the file, the line, what is wrong, and what to do instead.

The goal is simple:

The comments you eventually get from your peers should be about high-level design decisions — not trivial things you could have caught yourself.

You get serious brownie points for consistently raising high-quality, pre-vetted PRs.

Scaling the Process

Not every PR needs all four phases.

A 10-line config change → quick pass
A 1,000-line refactor → full deep review

Match the depth of review to the risk and complexity.

Over-reviewing small changes is wasteful.
Under-reviewing large ones is dangerous.

Final Thoughts

I am not offloading my thinking to an AI. I am using it to explore faster, validate assumptions, and stress-test decisions. The thinking is still mine.

The leverage is new.
The responsibility isn’t.

These tools are incredibly powerful — but you still need to hold the leash.

I’ve open-sourced the prompts and guidelines I use:
https://github.com/rajkundalia/ai-code-review-prompts

If you have better ideas, improvements, or ways to reduce noise — I’d genuinely like to see them.

cursor-claude-personas: Give Your AI Coding Assistant a Domain Expert Brain in 30 Seconds

Fri, 17 Apr 2026 22:44:50 +0000

cursor-claude-personas: Give Your AI Coding Assistant a Domain Expert Brain in 30 Seconds

TL;DR — cursor-claude-personas is a free, open-source collection of 38 role-based AI persona packs for Claude Code, Cursor, and VS Code. Copy one folder into your project, reopen your editor, and your AI assistant instantly behaves like a seasoned specialist — whether that's a senior Python developer, a DevOps engineer, a security expert, or a UI/UX designer.

The Problem: Generic AI Gives Generic Code

You have Claude Code or Cursor open. You ask it to add an endpoint. It writes something that works — but it doesn't know your preferred framework patterns, it doesn't follow your domain conventions, and it certainly doesn't remember that you care deeply about SQL index hygiene or GraphQL schema design.

The usual fix is a long system prompt you paste in every time. Or a .cursorrules file you spend hours writing. Or endless back-and-forth corrections.

cursor-claude-personas solves this with a dead-simple copy-paste.

What Is cursor-claude-personas?

cursor-claude-personas is a GitHub repository containing 38 ready-made persona packs for AI coding tools. Each persona is a folder with two hidden subdirectories:

senior-python-developer/
├── .claude/
│   ├── rules/       ← always-on instructions Claude Code reads at session start
│   └── skills/      ← auto-triggered skill docs for specific tasks
└── .cursor/
    ├── rules/       ← always-on instructions Cursor reads at session start
    └── skills/      ← auto-triggered skill docs for specific tasks

When you copy .claude/ or .cursor/ (or both) into the root of your project, your editor loads those configs automatically. No slash commands. No system prompts. The persona is live the moment you start a new chat session.

Supported tools

Tool	What to copy
Claude Code	`.claude/` folder
Cursor	`.cursor/` folder
VS Code	`.claude/` folder (when using Claude-based extensions)

How to Use It — Step by Step

Step 1: Clone the repo

git clone https://github.com/ratnesh-maurya/cursor-claude-personas.git

You only need to clone it once. Keep it around as your personal AI persona library.

Step 2: Pick the persona that matches your current work

Browse the table in the next section or visit the GitHub Pages site to filter by technology or tag.

Step 3: Copy the persona into your project

Navigate to your cloned copy and run:

# Claude Code only
cp -R cursor-claude-personas/senior-python-developer/.claude /path/to/your-project/

# Cursor only
cp -R cursor-claude-personas/senior-python-developer/.cursor /path/to/your-project/

# Both tools
cp -R cursor-claude-personas/senior-python-developer/.claude /path/to/your-project/
cp -R cursor-claude-personas/senior-python-developer/.cursor /path/to/your-project/

Replace senior-python-developer with any persona slug from the list below.

Step 4: Reopen your editor or start a new session

Claude Code and Cursor reload configuration at session start. From that point on, the AI follows the persona's rules, applies its skills automatically, and behaves as a domain expert — without you typing a single extra word.

Bonus: Enable the auto-skill router

Each persona includes a special rule file called rules--auto-skill-router.mdc (.mdc is the Cursor/Claude rule file format — it is just Markdown with optional YAML frontmatter). This rule tells the AI to automatically select the right skill doc based on what you're working on — so you never need to type /skill commands manually.

It is already included when you copy the persona folders. No extra steps required.

All 38 Personas

Persona	Best for
`3d-frontend-developer`	Three.js, WebGL, 3D UI
`ai-agent-developer`	LLM agents, tool use, orchestration
`ai-ml-engineer`	Model training, pipelines, MLOps
`azure-developer`	Azure services, ARM/Bicep, AKS
`blockchain-web3-developer`	Smart contracts, DeFi, Web3 tooling
`blog-website-developer`	Content sites, CMS, static generators
`data-engineer`	Pipelines, dbt, Spark, warehouses
`devops-cloud-engineer`	CI/CD, Kubernetes, IaC, observability
`ecommerce-specialist`	Shopify, WooCommerce, checkout flows
`fullstack-saas-mvp`	Rapid SaaS prototyping, full-stack
`functional-programming`	Haskell, Clojure, FP patterns
`game-developer`	Unity, Godot, game loops
`health-tech-developer`	FHIR, HL7, medical data systems
`legal-finance-analyst`	Contracts, compliance, financial models
`marketing-automation`	Email, CRM integrations, analytics
`mobile-developer`	React Native, Flutter, iOS/Android
`n8n-automation-specialist`	n8n workflows, low-code automation
`odoo-erp-specialist`	Odoo modules, ERP customization
`open-source-maintainer`	OSS governance, reviews, releases
`platform-integrations`	APIs, webhooks, third-party services
`product-manager`	Roadmaps, specs, user stories
`qa-testing-engineer`	Test strategy, automation, coverage
`saas-startup-founder`	GTM, metrics, early-stage decisions
`security-engineer`	Threat modeling, hardening, audits
`senior-dotnet-developer`	C#, ASP.NET Core, Azure
`senior-elixir-developer`	Elixir, Phoenix, OTP
`senior-frontend-developer`	React, TypeScript, frontend architecture
`senior-golang-developer`	Go, microservices, concurrency
`senior-java-developer`	Java, Spring Boot, enterprise patterns
`senior-python-developer`	Python, APIs, automation, data
`senior-rust-developer`	Rust, systems programming, WASM
`seo-specialist`	Technical SEO, Core Web Vitals, schema
`system-architect`	Service boundaries, scalability, design
`system-designer`	Low-level system design, algorithms
`technical-writer`	Docs, onboarding, API clarity
`ui-ux-designer`	Design systems, accessibility, UX
`voice-ai-developer`	Voice interfaces, TTS, STT, ASR
`wordpress-specialist`	WordPress, WooCommerce, theme dev

Not sure where to start? Try senior-python-developer or senior-frontend-developer — both are polished starting points that work for a wide range of projects.

What Makes This Different From a `.cursorrules` File?

A .cursorrules file (a single plain-text file at the project root) you write yourself usually contains two or three paragraphs of general instructions. Cursor also supports a .cursor/rules/ directory of individual rule files for more granular control. Both are fine for broad guidance, but neither gives your AI assistant real domain depth out of the box.

cursor-claude-personas packs in:

Multiple focused rule files — each covering a specific concern (schema design, security, pagination, query patterns, etc.) rather than one sprawling blob of text.
Skill documents — structured reference files that are automatically surfaced when the AI detects it needs them, without you prompting it.
Both tool formats simultaneously — the same expertise loads whether you are using Claude Code, Cursor, or VS Code Copilot.
Zero prompt engineering on your part — you copy two folders and you are done.

The key design principle is depth over breadth: one sharp specialist beats five vague generalists.

Real-World Example

Imagine you are building a Python REST API with PostgreSQL. You copy in the senior-python-developer persona. From that point on, when you write a query, the AI:

Warns you against WHERE id IN (SELECT ...) and rewrites it as WHERE id = ANY(ARRAY[...]) with a note about the 10× speedup.
Adds WHERE deleted_at IS NULL partial indexes automatically when it sees soft-delete columns.
Flags missing foreign key indexes before you even run EXPLAIN ANALYZE.
Enforces proper connection pool limits and prepared statement patterns.

None of that required you to type a single instruction. It was all encoded in the rules and skills you copied in.

How the Folder Structure Works Under the Hood

Each persona ships with two kinds of config files:

Rules (`rules/`)

Rules are always-on markdown files the editor reads at the start of every session. They define the persona's defaults, code style, anti-patterns to avoid, and domain-specific best practices. They are named with a rules-- prefix so they sort together and are easy to identify.

Skills (`skills/`)

Skill documents are structured markdown files with YAML frontmatter. The auto-skill router rule tells the AI to load the relevant skill when it detects you are working on a related task. For example, if you start writing an index migration, the SQL indexing skill is surfaced automatically. If you start wiring up an authentication flow, the auth skill fires.

This means the AI pulls in deep, specific guidance exactly when it is relevant — not all at once, cluttering its context.

Switching Personas Mid-Project

You can swap personas at any time. Just delete the existing .claude/ and .cursor/ folders in your project and copy in a different persona. Reopen your session and the new persona is live.

You can even mix rules from multiple personas manually if you know what you are doing, but most of the time a single focused persona is all you need.

Contributing a New Persona

The project is open source under the MIT license and welcomes contributions. If you want to add a new persona:

Fork the repository.
Create a new folder named after the role (e.g., data-science-researcher).
Add matching .claude/ and .cursor/ subdirectories with rules and skills.
Make sure the two directories are in sync — the parity check in CONTRIBUTING.md validates this.
Open a pull request.

See CONTRIBUTING.md for branch naming conventions, commit message format, and the full persona checklist.

Where to Get It

GitHub repository: https://github.com/ratnesh-maurya/cursor-claude-personas
GitHub Pages site (browse and filter personas): https://ratnesh-maurya.github.io/cursor-claude-personas/
License: MIT — free for personal and commercial use.

If it saves you time, star the repo. It helps other developers discover it.

Summary


What it is	38 role-based AI persona packs for Claude Code, Cursor, and VS Code
What it does	Shapes your AI coding assistant into a domain specialist — instantly
How to install	Clone the repo, copy one persona folder, reopen your editor
Time to set up	Under 30 seconds
Cost	Free and open source (MIT)
Requires	Claude Code, Cursor, or VS Code with Copilot

Clone it, copy a persona, and ship better code.

I’ve been producing bad code (because of AI)

Fri, 03 Apr 2026 19:37:30 +0000

I’ve been producing bad code for the past year. Not because I forgot how to code—because I’ve been trying to delegate everything to AI.

New research shows experienced developers are 19% slower with AI—but feel 20% faster. That’s a 40 percentage point gap between perception and reality.

In this video, I walk through three major studies that prove what many of us suspect but don’t want to admit: AI isn’t making us faster. It’s making us understand less, trust less, and ship code we can’t debug.

What You’ll Learn

The Speed Mirage: Why you feel productive but the data says otherwise
The Confidence Boundary: What to delegate vs what to keep
Infrastructure First: Specs + ADRs that make AI actually useful

This isn’t anti-AI. I use it every day. But the lie that it makes everything magically faster? That needs to die.

Confidence over throughput. That’s the bet I’m making.

Research sources and full transcript available in the video description.

The post I’ve been producing bad code (because of AI) appeared first on sudoish.

How to use the DHT22 sensor with ESP8266?

Fri, 03 Apr 2026 10:24:39 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

In this article, I will be explaining how to use DHT22 sensor with ESP8266.

Setup Requirements

Most of use confuse with DHT11 and DHT22.

Both are temperature and humidity sensors. But they have different specifications.

DHT22 is more accurate than DHT11.

For visual identification, DT22 comes in white color while DHT11 comes in blue color.

Once this is correctly identified, and have a datasheet with us. We can proceed with the setup.

Integrate Using Pre-built Libraries.

Most of the sensor manufacturers provide libraries for their sensors. Also if they don't provide libraries, we can find libraries for them in the internet.

Mostly we can use arduino IDE for searching libraries.

we can use platformio by just adding the library name in the lib_deps section of platformio.ini file.

PlatformIO Setup

Go to PlatformIO extension in VSCode.

Click on Create New Project.

Give Project Name.
Select the board in my case it was NodeMCU 1.0 (ESP-12E Module).
Select Framework as Arduino.

You can see platformio.ini file with the following content:

; PlatformIO Project Configuration File
;
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html
; Common settings for both environments
; Common settings for both environments
[env]
platform = espressif8266
board = nodemcuv2
framework = arduino
monitor_speed = 115200

How to Code for DHT22 Sensor with ESP8266?

Now we setup project

Let's add library for DHT sensor.

lib_deps = 
    adafruit/DHT sensor library@^1.4.4

In the main code let's add the following code.

#include "DHT.h"

// Define the NodeMCU pin connected to the DHT22 data pin
#define DHTPIN D2     

// Define the sensor type
// If yours is DHT11, then change it to DHT11

#define DHTTYPE DHT22   

// Initialize the DHT sensor
DHT dht(DHTPIN, DHTTYPE);

void setup() {
  // Start the serial communication
  Serial.begin(115200);
  Serial.println(F("DHT22 Sensor Test with NodeMCU!"));

  // Start the sensor
  dht.begin();
}

void loop() {
  // Wait a few seconds between measurements.
  // The DHT22 requires about 2 seconds to stabilize between readings.
  delay(2000);

  // Read humidity
  float h = dht.readHumidity();
  // Read temperature as Celsius (the default)
  float t = dht.readTemperature();
  // Read temperature as Fahrenheit (isFahrenheit = true)
  float f = dht.readTemperature(true);

  // Check if any reads failed and exit early (to try again).
  if (isnan(h) || isnan(t) || isnan(f)) {
    Serial.println(F("Failed to read from DHT sensor!"));
    return;
  }

  // Compute heat index in Fahrenheit (the default)
  float hif = dht.computeHeatIndex(f, h);
  // Compute heat index in Celsius (isFahreheit = false)
  float hic = dht.computeHeatIndex(t, h, false);

  // Print the results to the Serial Monitor
  Serial.print(F("Humidity: "));
  Serial.print(h);
  Serial.print(F("%  Temperature: "));
  Serial.print(t);
  Serial.print(F("°C "));
  Serial.print(f);
  Serial.print(F("°F  Heat index: "));
  Serial.print(hic);
  Serial.print(F("°C "));
  Serial.print(hif);
  Serial.println(F("°F"));
}

In here we are setting up the DHT22 sensor with ESP8266.

Initialize DHT sensor.

Start DHT sensor.

Read humidity.

Read temperature.

Read heat index.

Print the results.

Compile and Connection of DHT22 with ESP8266

Now we can see tick mark in the bottom of the VSCode.

On clicking it we can verify the code is compiling.

Output 1:

Checking size .pio/build/sensor_node_1/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [===       ]  34.5% (used 28236 bytes from 81920 bytes)
Flash: [===       ]  26.3% (used 274819 bytes from 1044464 bytes)
======================================================================= [SUCCESS] Took 0.56 seconds =======================================================================

After compilation we can upload the code to the ESP8266 by clicking the upload button.

Now we can connect the vin pin of DHT22 to 3V3 pin of ESP8266 and gnd pin of DHT22 to gnd pin of ESP8266.
Data pin of DHT22 to D2 pin of ESP8266.

Uploading the code to ESP8266

Connect ESP8266 to the computer and click on arrow button.

Output 2:

Writing at 0x0002c000... (92 %)
Writing at 0x00030000... (100 %)
Wrote 278976 bytes (204732 compressed) at 0x00000000 in 18.0 seconds (effective 123.7 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Finally we can see the output in the serial monitor on clicking socket button.

Output 3:

DHT22 Sensor Test with NodeMCU!
Humidity: 51.80%  Temperature: 31.30°C 88.34°F  Heat index: 33.51°C 92.31°F
Humidity: 51.80%  Temperature: 31.30°C 88.34°F  Heat index: 33.51°C 92.31°F
Humidity: 51.80%  Temperature: 31.30°C 88.34°F  Heat index: 33.51°C 92.31°F
Humidity: 51.70%  Temperature: 31.30°C 88.34°F  Heat index: 33.49°C 92.27°F

Conclusion

Now we could able to setup and test DHT22 sensor with ESP8266.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Introduction to Go generics?

Mon, 30 Mar 2026 21:36:35 +0000

Hello, I'm Ganesh Kumar. I'm working on git-lrc: a Git hook for Checking AI generated code.AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

In my previous post, I explained how to work with an interface.

Now let's understand go generics.

Why is Go Generics needed?

Before I start explaining go generics, let me give an example of a simple code without using go generics.

Let's have a simple function for finding the index of the element.
We can see that both internal workings are the same, but the parameters and return variable types are different




package main

import "fmt"



func IndexInt (s []int,x int) int{

    for i, v := range s{
        if v == x{
            return i
 }

 } 
        return -1

}

func IndexString (s []string,x string) int{

    for i, v := range s{
        if v == x{
            return i
 }

 } 
        return -1

}


func main(){

    integer := []int{10,20,30,35,40,45}
    fmt.Println(IndexInt(integer, 35)) 

    strings := []string{"hello", "world"}
    fmt.Println(IndexString(strings, "example")) 
}

As we can see, both are working in the same way.
Output:

gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
3
-1

So, why can't we have a single function that does the same task with passing different types? This is how go generics play a major role in this.

What is Go Generics?

It is a feature that allows developers to write reusable, type-safe code that works with multiple types.

That means we can use Go generics to solve our problem.

In the example below, we will solve the above problem.

Using Go Generics

There are many constraints to using go generics.

For our case let's just use a comparable constraint.

let't create function Index with [T comparable] with using T as type.


package main

import "fmt"



func Index[T comparable] (s []T,x T) int{

    for i, v := range s{
        if v == x{
            return i
 }

 } 
        return -1

}


func main(){

    integer := []int{10,20,30,35,40,45}
    fmt.Println(Index(integer, 35)) 

    strings := []string{"hello", "world"}
    fmt.Println(Index(strings, "example")) 
}

As we expected, we got the same results with one function.

Output

gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
3
-1

Conclusion

Go Generics was introduced recently we might be using it in a few cases where it is necessary.

Check out: git-lrc
Any feedback or contributors are welcome! It’s online, open-source, and ready for anyone to use.
⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

git-lrc-intro-60s.mp4

Why

AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
Build a habit, ship better code. Regular review → fewer bugs → more robust code → better results in your team.
Why git? Git is universal. Every editor, every IDE, every AI…

View on GitHub

Your Code Works. Your Architecture Doesn’t.

Sat, 28 Mar 2026 02:50:21 +0000

Why working code without architecture predictably collapses — and what to do about it.

Prefer watching? The full video covers everything in this post — with visuals and code walkthroughs.

The Code That Almost Took Down Black Friday

This code passed code review. Three senior developers approved it. It's been in production, serving real customers.

And it almost took down Black Friday.

Not because of a bug. Not because of performance. The code works. The architecture doesn't.

I've seen this exact story play out at every company I've worked at over the past decade. Different languages, different teams, same pattern. It's predictable. And it's preventable.

The Handler

Here's the code. Tell me if this looks familiar.

One handler function. About a hundred and seventy lines. And it does everything.

Top third — database queries to get product prices, discount calculations, tax logic.
Middle — Stripe payment processing.
Bottom — saving to the database, sending confirmation emails.

Business logic, infrastructure, third-party APIs — all in one function. Mixed together.

And if you're being fair? This code is fine. It works. It's readable. It handles errors properly. Three senior developers approved this PR. I would too.

And that's the trap.

Because it's not about whether this code works today. It's about what happens when you try to extend it.

The Timeline: From Ship It to Rewrite

Let me walk you through what actually happens. Week by week. This isn't theoretical — I've lived through this pattern multiple times.

Week one. Feature ships. Everyone's happy. PR approved, tests pass, production is stable. The team feels fast. And they ARE fast. This is real.

Week three. New requirement: show product prices in the cart endpoint. Developer needs product prices. Opens the order handler. Sees the query. Copy-pastes it into the new handler. Fastest way to meet the deadline. Small duplication. Seems fine.

Week five. Someone notices the duplication. Creates a helper function. Good instinct. But the order handler still has the inline version. The cart handler still has the copy-pasted version. Only new code uses the helper. Now you have three ways to get a product price in the same codebase.

Week seven. Three developers, three different approaches. One returns just the price. Another returns an object. A third returns a dictionary. No agreed pattern. Everyone solving the same problem their own way.

Week ten. Circular dependencies start forming. Orders depend on products. Products depend on discounts. Discounts depend on orders for loyalty calculations. Everything depends on everything. Can't test anything in isolation. Can't change one thing without breaking another.

Month six. The test suite takes forty-five minutes. Nobody runs it anymore. Production bugs are weekly. Simple changes take days because everyone's scared of breaking something.

And the developer who wrote that first handler? The one who shipped on time, passed code review, got the thumbs up? They're looking at the same code thinking — how did we get here? I did everything right.

And here's the sentence I've heard at every single one of these companies:

"We're talking about a rewrite."

Six months. Working code. Senior developers. Good intentions. And you're talking about throwing it all away.

Every codebase has an architecture. If you didn't choose one, you got one anyway — by accident. That handler? That IS an architecture. It's just not one anyone decided on. It's the one that happened when nobody made a choice.

And accidental architecture always ends the same way.

The AI Amplifier

Now here's where it gets worse.

Everything I just described? That timeline assumed humans writing code at human speed. Add AI to a codebase with no architecture and you don't just get the same problems. You get them ten times faster.

Think about it. You prompt your AI: "add a loyalty points discount feature." The AI looks at your codebase. It sees four different patterns for handling discounts. It picks one. Maybe creates a fifth. It generates code following that pattern — whatever pattern it found first.

Now you have five patterns. The AI didn't fix anything. It photocopied the mess at ten times the speed.

AI doesn't fix architecture. It amplifies whatever exists.

Good architecture? AI follows clean patterns. You get consistency at ten times the speed. No architecture? AI copies chaos. You get spaghetti at ten times the speed.

If you're planning to use AI — and you should be — you need better architecture, not less.

What To Actually Do

So what do you actually do about it?

Let me take that same handler and show you one decision that changes everything. You don't need to rewrite this. You need to pull it apart.

Step one: Take the business logic out. Discount rules, tax calculations, order totals — that's your business. It doesn't need to know about HTTP. It doesn't need to know about Stripe. It's just math.

Step two: Take the infrastructure out. Stripe, the database, email — those are tools. They serve the business logic. They shouldn't live with it.

Step three: What's left is the glue. Your handler just receives a request and passes it along. That's all it should ever do.

Now look at what you've got:

domain/
  models.py             — business rules
services/
  order_service.py      — orchestration
adapters/
  stripe_payment.py     — payment infra
  db_repositories.py    — data access
routes/
  orders.py             — HTTP, thin

That's hexagonal architecture.

You didn't plan it on a whiteboard for six months. You just asked one question about the code you already had: what belongs together, and what doesn't?

I'm not telling you to architect everything before writing your first line of code. That first handler? Ship it. Get it working. Pass code review. But somewhere between that first handler and the moment your codebase starts growing — before the copy-paste starts, before three developers create three patterns — make the decision.

Because the window where this is easy? It closes fast. Week one, it's a two-hour refactor. Month six, it's a rewrite. The only difference is when you chose to think about structure.

And once you have it — look at what changes:

Debugging a discount bug? One file. Twenty-five lines. Pure math.
New developer joins? They know where code goes on day one.
Tests? Under a millisecond. You actually run them.
AI generates code? It sees clean separation. It follows the pattern instead of copying chaos.

Three Things To Do This Week

One. Ask your team: "Where does new code go?" If nobody has a clear answer — that's your window. It's still open.

Two. Pick one piece of business logic buried in a handler. Extract it into a pure function. No dependencies. Just inputs and outputs. Write a test. Feel how fast it runs.

Three. Next time someone opens a PR with copy-pasted logic — don't just approve it. That's the moment the spaghetti starts. Be the person who says "let's extract this."

None of these take more than thirty minutes. All of them compound.

The Honest Trade

I'm not going to pretend there's no cost. Your first feature with architecture takes a bit longer. You're thinking about structure, defining boundaries.

But here's the thing that doesn't show up in sprint metrics but everyone feels: developer confidence.

When your code has clear boundaries, you're not scared to change things. You run your tests, they pass in seconds, you deploy. No sweating. No "let me check if this breaks the payment flow."

That feeling? That's what architecture gives you. Not just speed. Confidence. The confidence that the next Black Friday won't be yours.

Quick Gut Check

How many of these sound like your codebase right now?

"We're talking about a rewrite."
"I don't know which version of this function is the right one."
"The new developer asked where to put their code and nobody had an answer."

If any of those hit — you don't have technical debt. You have an architecture problem.

Hexagonal architecture is what I showed you today. It's what worked for me across many different projects and languages. But it's not the only answer. There's microkernel, event-driven, and dozens of other proven patterns. Go take a software architecture course on LinkedIn Learning or Coursera — people have spent decades figuring this stuff out. You don't have to invent the wheel. You just have to actually use one.

Because the difference between a codebase that scales and one that collapses? It's not talent. It's not the language. It's not even the framework. It's whether someone sat down and made a plan.

There's also a GitHub repo with the code so you can see this pattern for real. If you want to see the practical side — how to actually refactor this into clean architecture, step by step — that's the next video. Subscribe so you don't miss it.

The post Your Code Works. Your Architecture Doesn’t. appeared first on sudoish.

The Repo Is Right There. Why Are You Checking Their CV?

Fri, 27 Mar 2026 15:05:49 +0000

Choose A, B or C

Someone posts this on LinkedIn:

“I implemented a numerical algorithm to validate string theory vacuum consistency. Built with NumPy, not PyTorch. Repo below.”

What do you do first?

A) Open their profile. University, publications, credentials.

B) Click the repo. Read the README. Try to run it.

C) Scroll past.

C means you’re not in this field. Fine.

But if you work in AI, you chose A or B. That instinct reveals more about where this industry is cracking than any benchmark announcement in 2026.

Your answer depends on your destination

If you chose A, you are probably operating inside a world where that instinct makes sense. That’s not a criticism — it’s the logic of the job.

A researcher’s destination is reputation. Citations, SOTA results, conference invitations. Checking credentials is rational in that world. A paper from an unknown author with no affiliation is genuinely harder to evaluate. The system makes sense, inside that world.

An engineer’s destination is something that runs. Ships. Doesn’t break at 2am. The only signal that matters is the working artifact. That system makes sense, inside a different world.

Neither instinct is wrong. The problem is that both worlds now use the same words for different things.

I’ve built enough systems that looked correct in testing and failed in production to know the difference. A result that doesn’t survive real conditions isn’t a result. It’s a failure with good cosmetics. That understanding changes how you read a repo. It changes which questions you even think to ask.

A researcher reading the same repo is asking: is this idea novel? Does this advance the field? Real questions. Just not the ones I need at 2am.

This looks like a communication problem on the surface. It isn’t. It is an incentive problem with a vocabulary leak. Before 2025, the gap was mostly about speed — how long research took to reach production. What changed is the nature of the gap itself. It became semantic. The same words now describe different realities depending on who’s using them.

That leak has a cost. And it accumulates.

The field is drowning in unconsumed insight

The AI field is not short on intelligence. It is drowning in unconsumed insight.

Ideas that are real, verified, published, cited. Ideas that never survive the journey from the lab to somewhere something actually needs to run.

Most people assume the bottleneck is the model. It isn’t.

ML code is roughly 5% of a production system.1 The other 95% is data pipelines, monitoring, error handling, cost controls. That’s where technical debt compounds. That’s also where researchers rarely look, because it doesn’t generate publishable results.

A paper reports near-perfect efficiency on a benchmark dataset. Clean data, controlled compute, no legacy systems, no users doing unexpected things. When that paper meets a real system, the promised behavior sometimes doesn’t degrade. It simply doesn’t appear.

Think of every research paper as a Michelin-starred recipe. Precise, rigorous, tested — in the chef’s kitchen. When someone else tries to cook the same dish, the recipe isn’t wrong. It was just never written for their kitchen, their ingredients, their equipment. Most AI papers are the same. The research works. The conditions don’t transfer.

The recipe problem doesn’t stay in the lab. It follows the system into production — and there, the stakes change.

Relatived Post:

\[When the Michelin Recipe Fails in Your Kitchen\]

Capability and reliability do not scale on the same curve

Autonomous task duration in AI systems grew from 4 minutes in early 2024 to 14.5 hours by February 2026. Real progress. But chain 20 steps together in production, and end-to-end success rates fall to around 36%, even at 95% per-step reliability. Error multiplies. 91% of ML models degrade after deployment. Fewer than 10% of enterprises have anything resembling agent governance.2

Capability and reliability do not scale on the same curve.

There’s also a perception problem that makes this harder to see. The METR study from 2025 tracked experienced software developers completing realistic engineering tasks — debugging, feature implementation, code review — using Cursor Pro with Claude 3.5/3.7 Sonnet. Objective measurement: 19% slower. Self-reported: 20% faster. A 39-point gap.3 Not a technology failure. What happens when your destination (feeling productive) diverges from the destination that matters (the system works, the product ships).

Researchers and engineers are measuring the same industry with instruments calibrated for different purposes. Both instruments work correctly. They just don’t measure the same thing.

So who closes the gap? It starts with the vocabulary.

When the same word means opposite things

In October 2025, Andrej Karpathy appeared on the Dwarkesh Patel podcast and defined what he meant by “agent.” An employee. An intern you could actually delegate to. A system with enough intelligence, memory, and reliability to do the work.

His listeners immediately noticed the problem. Blogger Simon Willison wrote: “It turns out Andrej is using a different definition of agents to the one that I prefer.”

Nobody was wrong. They were just using the same word from different worlds.

To a researcher, an agent is an autonomous goal-directed entity with planning capabilities and long-horizon reasoning. That definition comes from decades of AI literature and it’s precise within that tradition.

To an engineer in 2026, an agent is something different. It’s a system with tool-calling, retry logic, and an observability layer that you’ve tuned until it stops crashing in ways that cost money. A 70% end-to-end success rate is cause for genuine celebration. Shipping at 36% is sometimes acceptable if the fallback is graceful enough.

These aren’t different opinions about the same thing. They’re different objects that inherited the same name.

The same drift happened to “scaling,” “alignment,” and “AGI.” Each word started in one world and got adopted by the other without the definition transferring. When a researcher and an engineer read the same post about agents and each thinks the other doesn’t understand, they’re often both right. They’re evaluating different claims.

“Agents in papers vs agents in prod — night and day.” That line circulated on r/AI_Agents in late 2025. It kept being cited not because it was clever. Because it named something people had been experiencing without language for it.

So who builds the translation layer?

The bridge gets built by individuals

The obvious answer is institutions. Academic-industry partnerships, joint research labs, government-funded translation programs.

In practice, it rarely works cleanly. Authorship disputes, IP complications, publication timelines running perpendicular to shipping timelines. The institutions themselves are optimized for the wrong destination to close this gap.

What actually closes the gap looks nothing like an institution. It looks like one person who needed the thing to run, and had enough theoretical grounding to make it run right.

Ollama is one example. A small team was frustrated that running models locally required too much configuration. Now it’s ollama run llama3. One command. 100,000+ GitHub stars. Not a university project. Just people who wanted it to work on their own machines.

The honest counter: Ollama eventually attracted investment. So did Hugging Face, vLLM, and most of the other tools that closed the research-production gap. Institutions end up involved.

The claim is about sequence. In each case, someone decided the paper wasn’t enough and built the bridge before any institution sanctioned it. The initial translation from “this works in a paper” to “this works in your terminal” came from individuals whose primary motivation was running the thing. Funding arrived after the bridge existed, not before.

Big tech noticed. And drew exactly the wrong conclusion.

What the talent wars actually show

If individuals close the gap, the logic goes, buy the individuals. Pay enough, and the outcome follows.

Meta reportedly paid around $200M to bring Ruoming Pang from Apple in July 2025. He moved to OpenAI seven months later. The reporting around why is incomplete. But even if the details are contested, the pattern is familiar to anyone who has watched this play out inside organizations.

Money can relocate a person. It can’t relocate their definition of done.

OpenAI re-hired Pang. Both companies keep acquiring research prestige and attempting to convert it to production output. The conversion step is where the collision lives, every time.

The ARR numbers — OpenAI at roughly $25B, Anthropic at roughly $19B — tell a limited story. OpenAI has the user base and capital. What’s factually observable is that Anthropic’s strongest growth is in enterprise and coding.

Those buyers write reliability requirements into procurement documents. Whether that reflects the research-production gap being priced by the market, or simply different go-to-market choices, the data doesn’t settle it.

This is the actual frontier

Research produces ideas in one language. Production tries to implement them in another. The translation layer between them still doesn’t exist. That gap is where most AI projects actually fail — not in the model, not in the benchmark, but in the distance between the two.

The next meaningful advances won’t come from bigger benchmarks. They’ll come from whoever closes the distance between “works in the paper” and “works in the hospital, the factory, the government office, the small team with one overworked engineer.”

Nobody is writing LinkedIn posts about that work. It doesn’t look like progress from the outside. It just looks like something finally running.

The insight exists. The kitchen keeps failing it.

The two clicks that reveal everything

So back to that LinkedIn post. The string theory algorithm. NumPy. Repo below.

A) You opened their profile.

B) You clicked the repo.

Has your answer changed?

If it has, even slightly — that’s not small. The gap between those two instincts is the gap this field most needs to close.

References

Sculley, D. et al. “Hidden Technical Debt in Machine Learning Systems.” NIPS 2015. The 5% figure (ML code as fraction of total production system) originates here and has been widely cited since.
Radoff, Jon. “The State of AI Agents in 2026.” Metavert Meditations (Substack), February 24, 2026.
Becker, Joel et al. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” METR, July 2025. — arXiv: 2507.09089
Willison, Simon. “Notes from the Dwarkesh Patel / Andrej Karpathy podcast.” simonwillison.net, October 2025.

Understanding Methods in Go

Wed, 25 Mar 2026 22:30:59 +0000

In my previous post, I explained how closure works.

In this article we will understand how to method works.

Method

Method is a function with a receiver.

This works like a class method in other languages.

Here is the example of method.

let's define a struct value and add method to it.


package main

import "fmt"


type value struct {
    X, Y int
}



func (v value) add() int {

return v.X + v.Y
}

func main() {
    val := value{1,2}

    fmt.Println(val.add())
    val2 := &value{1,2}
    fmt.Println(val2.add())
}

Output:

gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
3

This is a simple example of method.

Pointer receiver

Pointer receiver is used to modify the value of the struct.


package main

import "fmt"


type value struct {
    X, Y int
}



func (v *value) add() int {

v.X += 1
v.Y += 1
return v.X + v.Y
}

func main() {
    val := value{1,2}
    fmt.Println(val.add())
    println(val.X,val.Y)
}

Output:

gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
3
2 3

From this we can see that pointer receiver is used to modify the value of the struct.

Conclusion

In this article we understood how method works and how pointer receiver is used to modify the value of the struct.

Check out: git-lrc
Any feedback or contributors are welcome! It’s online, open-source, and ready for anyone to use.
⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

git-lrc-intro-60s.mp4

Why

AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
Build a habit, ship better code. Regular review → fewer bugs → more robust code → better results in your team.
Why git? Git is universal. Every editor, every IDE, every AI…

View on GitHub

Understanding Anonymous Functions in Go

Mon, 23 Mar 2026 22:29:30 +0000

In my previous post, I explained what are maps and how to create them.

Now let's see how anonymous functions created and understand how it works.

Anonymous functions

We assign a function to a variable and then call it.


package main

import "fmt"


func main() {
    data := func() {
        fmt.Println("Hello World")
    }

    data()
}

Hello World

Similarly we can also pass arguments to the anonymous function.


package main

import "fmt"


func main() {
    data := func(a,b string) {
        fmt.Println(a,b)
    }

    data("dev","to")
}

Output:

dev to

Passing function as an argument

We are passing a function as an argument to another function.


package main

import "fmt"

func anonymous(a func()) {
    a()
}
func main() {
    data := func() {
        fmt.Println("Hello World")
    }
    anonymous(data)
}

Output:

Hello World

If we want to pass arguments to the anonymous function, we can do it like this:


package main

import "fmt"

func anonymous(a func(string,string)) {
    a("dev","to")
}
func main() {
    data := func(a,b string) {
        fmt.Println(a,b)
    }
    anonymous(data)
}

As is the print statement is inside the anonymous function, it is printing the values passed to it.

Output:

dev to

Conclusion

We understood how the anonymous functions are created and how to pass them as arguments to another function.

As go has the feature of passing functions as arguments to another function, go provides a feature called closure.

Check out: git-lrc
Any feedback or contributors are welcome! It’s online, open-source, and ready for anyone to use.
⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

git-lrc-intro-60s.mp4

Why

AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
Build a habit, ship better code. Regular review → fewer bugs → more robust code → better results in your team.
Why git? Git is universal. Every editor, every IDE, every AI…

View on GitHub

https://github.com/golang/go/blob/master/src/runtime/slice.go

What Is a 6-Digit Verification Code? Why Sharing It Is a Major Security Risk

Mon, 23 Mar 2026 12:31:38 +0000

What Is a 6-Digit Verification Code? Why Sharing It Is a Major Security Risk

In our increasingly digital world, security is paramount. You have likely encountered a scenario where you try to log into an app or a bank website, and suddenly, your smartphone buzzes with a text message containing a random 6-digit number. This is a verification code, and while it seems like a simple, fleeting string of numbers, it is one of the most critical gatekeepers of your digital identity. Understanding what these codes are and, more importantly, why you should never share them, is a fundamental aspect of staying safe online.

What Exactly Is a 6-Digit Verification Code?

A 6-digit verification code—often referred to as a One-Time Password (OTP) or a Time-based One-Time Password (TOTP)—is a security mechanism used for identity verification. It is a core component of Multi-Factor Authentication (MFA) or Two-Factor Authentication (2FA).

When you attempt to log into a service, the system doesn’t just rely on your password. It sends a temporary, unique code to your registered device (usually via SMS, email, or an authenticator app) to prove that you are the one attempting the access. The code is time-sensitive, often expiring in a matter of minutes, rendering it useless if intercepted later.

The Role of MFA/2FA

MFA is designed to add a layer of protection that goes beyond just a password. If a hacker manages to steal your password in a data breach, they still cannot access your account without that secondary factor—the 6-digit code. It effectively bridges the gap between ‘what you know’ (your password) and ‘what you have’ (your phone).

Why You Should Never Share Your Verification Code

It sounds like common sense, but social engineering attacks rely on tricking users into divulging this code. Here is why sharing it is a dangerous mistake:

It Grants Total Access: To the service provider, whoever provides that code is the authorized user. By giving it to someone else, you are effectively granting them your digital ‘keys.’
Bypassing Security: Giving away your OTP renders your primary security layer (your password) completely obsolete.
Account Takeover (ATO): This is the ultimate goal of the attacker. Once they have your code, they can change your account password, change recovery email addresses, and lock you out completely.
Financial Theft: If the code is for your banking app or a digital wallet, the consequences can be immediate and devastating.

How Attackers Trick You Into Sharing Your Code

Hackers do not always ‘hack’ systems; often, they ‘hack’ humans. They use social engineering tactics to manipulate you into breaking your own security protocols. Here are common scenarios:

1. The Urgent Customer Support Scam

You receive a call or text claiming to be from your bank, Amazon, or a popular social media platform. They claim there is ‘suspicious activity’ on your account. They then ask you to read back the ‘verification code they just sent’ to ‘verify your identity’ or ‘stop the unauthorized transaction.’ They are the ones initiating the login attempt; they need your code to finalize the takeover.

2. The ‘Wrong Number’ Text

Someone messages you saying they accidentally sent a verification code to your phone. They ask you to forward it to them so they can fix their account. If you do, you have just provided the credentials for your own account, which they were attempting to hijack.

3. Fake Account Recovery Requests

An attacker may compromise a friend’s account and message you, pretending to be them, claiming they need your help to recover their account. They will instruct you to share a code that arrives on your phone. Never trust these, even if they come from a known contact.

What to Do If You’ve Shared Your Code

If you suspect you have mistakenly shared a verification code, act immediately:

Change Your Password: Immediately log into the affected service and change your password to something unique and strong.
Log Out Everywhere: Check the account security settings for an option to ‘Log out of all devices’ or ‘End all active sessions.’
Check for Changes: Verify if your recovery email, recovery phone number, or security questions have been changed.
Contact Support: Reach out to the official customer support channel of the service immediately to report a compromised account.
Monitor Financial Activity: If the account is linked to money, check your recent transactions and notify your bank if anything looks suspicious.

Best Practices for Keeping Your Accounts Secure

Beyond guarding your OTPs, here are proactive steps to enhance your security:

Enable 2FA Everywhere: Use MFA on every account that supports it, especially email, banking, and social media.
Use Authenticator Apps: Whenever possible, use authenticator apps (like Google Authenticator, Authy, or Microsoft Authenticator) instead of SMS. SMS messages can be intercepted through SIM swapping attacks, while authenticator apps are safer.
Never Trust Unexpected SMS: If you receive a 6-digit code when you didn’t request one, delete the message. Do not respond to it.
Use a Password Manager: A password manager helps you maintain complex, unique passwords for every site, reducing the risk of a breach affecting multiple accounts.

Conclusion

The 6-digit verification code is a small string of numbers that holds immense power. It is designed to be your last line of defense against account takeover. By recognizing the social engineering tactics used by hackers and maintaining a strict policy of never sharing these codes with anyone—under any circumstances—you drastically increase your digital security. Remember: No legitimate organization will ever ask you to share a verification code that they have sent to you via SMS. Stay vigilant, stay skeptical, and keep your accounts locked down.

Frequently Asked Questions (FAQ)

1. Can I share the code if a customer support representative asks for it?

No. Legitimate support agents will never ask for your verification code or password. If someone asks for it, it is a red flag for a scam.

2. What should I do if I get a code when I didn’t try to log in?

Do nothing. If you did not initiate a login attempt, ignore and delete the message. Someone may have your password and is trying to access your account, but as long as you do not give them the code, they cannot get in. You should consider changing your password for that account immediately as a precaution.

3. Are authenticator apps safer than SMS verification?

Yes. Authenticator apps generate codes locally on your device, making them immune to SMS interception techniques like SIM swapping. Always choose the authenticator app option when setting up 2FA.

4. What is a SIM swap attack?

A SIM swap attack occurs when a hacker convinces your mobile carrier to transfer your phone number to a SIM card in their possession. This allows them to receive your SMS messages, including your 2FA codes. This is why using an authenticator app or hardware security key is more secure than SMS.

5. Is there ever a safe reason to share a 6-digit code?

No. There is no legitimate scenario where a third party requires you to share a security code meant for your personal authentication.

The post What Is a 6-Digit Verification Code? Why Sharing It Is a Major Security Risk first appeared on Insight Ginie.

Understanding Closures in Go

Mon, 23 Mar 2026 10:11:14 +0000

In my previous post, I explained how anonymous functions created and understand how it works.

In this article we will understand how closure.

What is closure

A closure is a function value that references variables from outside its body.

The function may access and assign to the referenced variables; in this sense the function is "bound" to the variables.

How closure is used?

Each time new value updates the sum variable.

Next time when we call the function, it will use the updated value of sum.

So, It remembers the value of sum.


package main

import "fmt"
func adder(x int) func(int) int {
    sum := 0
    return func(y int) int {
        sum += y
        return sum
    }
}


func main() {
   pos,neg := adder(0),adder(0)
   for i := 0; i < 10; i++ {
        fmt.Println(
            pos(i),
            neg(-i),
        )
    }

}

Output:

gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
0 0
1 -1
3 -3
6 -6
10 -10
15 -15
21 -21
28 -28
36 -36
45 -45

Fibonacci series

Here is the example of fibonacci series.
initially we are initializing a and b with 0 and 1.

then with each time calling the function it will return the return value of a.

and update the value of a and b.

So, hence creating a fibonacci series.

package main

import "fmt"

// fibonacci is a function that returns
// a function that returns an int.
func fibonacci() func() int {
    a, b := 0, 1
    return func() int {
        ret := a
        a, b = b, a+b
        return ret
    }
}

func main() {
    f := fibonacci()
    for i := 0; i < 10; i++ {
        fmt.Println(f())
    }
}

Output:

gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
0
1
1
2
3
5
8
13
21
34

Conclusion

In this article we understood how closure is used. closure is a function value that references variables from outside its body.

Check out: git-lrc
Any feedback or contributors are welcome! It’s online, open-source, and ready for anyone to use.
⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

git-lrc-intro-60s.mp4

Why

AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
Build a habit, ship better code. Regular review → fewer bugs → more robust code → better results in your team.
Why git? Git is universal. Every editor, every IDE, every AI…

View on GitHub

Vibe Coding vs Prompt-Driven Development: Generative AI

Thu, 19 Mar 2026 02:43:56 +0000

Vibe Coding vs Prompt-Driven Development: Generative AI and Software Development, Security and Code Quality

The advent of generative artificial intelligences like ChatGPT, Claude, and GitHub Copilot has revolutionized how we design and write code. This transformation has given rise to two distinct approaches to AI-assisted development: Vibe Coding and Prompt-Driven Development.

Introduction: Two Philosophies, Two Approaches

In today’s software development ecosystem, we’re witnessing the emergence of two AI-assisted programming paradigms that reflect radically different philosophies:

Vibe Coding: The Intuitive Approach

Vibe Coding represents a spontaneous and intuitive approach to AI code generation. This method prioritizes execution speed and accessibility, allowing even non-developers to create functional solutions in minutes.

Vibe Coding Characteristics:

Short and generic prompts
Focus on immediate results
Quick iterations and on-the-fly corrections
“It works, that’s good” approach
Maximum accessibility for all profiles

Prompt-Driven Development: The Structured Approach

In contrast, Prompt-Driven Development (PDD) adopts a methodical and professional approach. This method treats AI as a sophisticated development partner, requiring precise and structured communication.

Prompt-Driven Development Characteristics:

Detailed prompts with technical context
Quality and security specifications
Defined architecture and patterns
Integrated tests and documentation
Maintenance and scalability as priorities

Comparative Analysis: Risks and Benefits

The Risks of Vibe Coding

1. Security Vulnerabilities

Vibe Coding often generates code with critical security flaws:

# Typical Vibe Coding example - DANGEROUS
def login(username, password):
    query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
    result = db.execute(query)
    return result.fetchone() is not None

This code presents an obvious SQL injection vulnerability but may appear functional during basic testing.

2. Lack of Structure and Maintainability

// Vibe Coding generated code - unmaintainable
function handleData(data) {
    if (data) {
        if (data.users) {
            for (let i = 0; i < data.users.length; i++) {
                if (data.users[i].active) {
                    document.getElementById('user-' + i).innerHTML = data.users[i].name;
                    if (data.users[i].role === 'admin') {
                        document.getElementById('admin-panel').style.display = 'block';
                    }
                }
            }
        }
    }
}

3. Absence of Error Handling

Vibe Coding generated code often neglects error handling and edge cases.

The Benefits of Prompt-Driven Development

1. Integrated Security

# Prompt-Driven Development with security
from werkzeug.security import check_password_hash
from sqlalchemy import text
import logging

def authenticate_user(username: str, password: str) -> Optional[User]:
    """
    Authenticates a user securely

    Args:
        username: Username (validated and escaped)
        password: Plain text password

    Returns:
        User object if authentication successful, None otherwise

    Raises:
        AuthenticationError: In case of authentication error
    """
    try:
        # Using parameterized query to prevent SQL injection
        query = text("SELECT id, username, password_hash, role FROM users WHERE username = :username")
        result = db.session.execute(query, {'username': username}).fetchone()

        if result and check_password_hash(result.password_hash, password):
            logging.info(f"Successful authentication for user: {username}")
            return User(id=result.id, username=result.username, role=result.role)

        logging.warning(f"Failed authentication attempt for user: {username}")
        return None

    except Exception as e:
        logging.error(f"Authentication error: {str(e)}")
        raise AuthenticationError("Authentication service unavailable")

2. Architecture and Patterns

// Prompt-Driven Development with clear architecture
interface UserRepository {
    findById(id: string): Promise<User | null>;
    findByUsername(username: string): Promise<User | null>;
    save(user: User): Promise<void>;
}

class UserService {
    constructor(
        private userRepository: UserRepository,
        private logger: Logger,
        private eventBus: EventBus
    ) {}

    async authenticateUser(credentials: LoginCredentials): Promise<AuthResult> {
        const validation = this.validateCredentials(credentials);
        if (!validation.isValid) {
            return AuthResult.failure(validation.errors);
        }

        try {
            const user = await this.userRepository.findByUsername(credentials.username);
            if (!user || !await this.verifyPassword(credentials.password, user.passwordHash)) {
                this.logger.warn('Failed authentication attempt', { username: credentials.username });
                return AuthResult.failure(['Invalid credentials']);
            }

            this.eventBus.publish(new UserAuthenticatedEvent(user.id));
            return AuthResult.success(user);

        } catch (error) {
            this.logger.error('Authentication service error', { error: error.message });
            throw new AuthenticationServiceError('Authentication unavailable');
        }
    }
}

Prompt Engineering for Professional Development

Structure of an Effective Prompt

A professional-quality prompt must include:

Precise technical context
Detailed functional specifications
Security and performance constraints
Code standards and patterns
Testing and documentation requirements

Example of Structured Prompt

CONTEXT:
E-commerce application in Node.js/TypeScript with PostgreSQL
Hexagonal architecture, unit tests with Jest
JWT authentication, validation with Joi

OBJECTIVE:
Create an order management service with functionalities:
- Order creation with business validation
- Automatic tax calculation based on geolocation
- Inventory management with availability check
- Client and admin notifications

TECHNICAL CONSTRAINTS:
- Use interfaces for dependency inversion
- Implement error handling with specific types
- Add structured logs for monitoring
- Unit tests with >90% coverage
- Complete JSDoc documentation

SECURITY CONSTRAINTS:
- Strict validation of user inputs
- Prevention of race conditions on inventory
- Audit trail for all operations
- Rate limiting on public endpoints

EXPECTED DELIVE

AI Code Reviews Are Backwards (Do This Instead)

Tue, 03 Mar 2026 02:48:21 +0000

A few weeks ago, I wrote about The Review Bottleneck — how AI-generated code comes with so much confident explanation that we’ve stopped actually reviewing it.

We’re not doing more engineering. We’re doing more trusting.

The response was overwhelming. Developers everywhere said: “I thought I was the only one.”

So I made a video breaking down what’s actually happening — and what I’m trying instead.

The Core Problem

AI code reviews aren’t making us better reviewers. They’re making us worse.

Not because the AI is bad — but because the volume of explanation has become impossible to process.

When you’re staring at:

300 lines of code
1,200 words of AI explanation
800 words of AI review feedback
15 inline comments about trade-offs

You’re not carefully evaluating. You’re skimming and trusting.

What I’m Doing Instead

The video walks through my current approach:

The 30-minute rule — If I can’t understand a PR in 30 minutes of focused review, it’s too big. Break it down.

No AI reviewer without human review — AI review is a supplement, not a replacement.

The explain-it test — If I can’t explain the core logic to someone else, I don’t approve it.

Does this slow me down? Yes.

Does it help? I think so.

The Uncomfortable Truth

Research shows AI-generated code creates 1.7x more issues than human-written code. Yet:

46% of all code is now AI-generated
84% of developers use AI coding tools regularly
Only 30% of AI-suggested code actually gets accepted

We’re generating more code than ever. But we’re not reviewing it properly.

The quality gate we automated away isn’t coming back.

We need to figure out what replaces it.

Watch the Full Breakdown

The video goes deeper into:

Why AI code review tools make the problem worse, not better
The “automation bias” trap we’re all falling into
Practical strategies for reviewing AI code honestly
What comes next when the review bottleneck becomes permanent

Check it out and let me know what you think. Are you actually reviewing AI code? Or just hoping the explanation is right?

Related: Read the full analysis in The Review Bottleneck: Why AI Explanations Are Making Us Trust Less, Not More

The post AI Code Reviews Are Backwards (Do This Instead) appeared first on sudoish.

A Tale of Accidental Architecture: How 50 Lines Became A Black Friday Disaster

Sat, 28 Feb 2026 03:46:54 +0000

Let me tell you about Sarah.

This is a fictional story. But I bet you’ll recognize it.

I’ve seen this pattern play out across different companies, different teams, different tech stacks. The details change. The progression doesn’t.

Week 1: The Perfect Start

Sarah’s building a notification system for an e-commerce platform.

First requirement: send an email when someone places an order.

Simple. She writes one function. Webhook comes in, format the email, hit SMTP, done.

The whole thing is maybe 50 lines. It works perfectly. Code review approves it. It ships.

Sarah’s thinking: “It’s just one notification type. I’ll add proper abstraction when we actually need it.”

You’ve thought this too. So have I.

Nothing wrong with it. Week 1, this is the right call.

Week 3: The First Copy-Paste

Product team loves the email notifications. Now they want SMS for order shipments.

Mike picks up the ticket.

He opens Sarah’s code. Sees the pattern. Makes sense. He follows it.

New handler. Receives the shipment webhook. Formats the SMS message. Connects to Twilio. Sends it.

He copies some of Sarah’s email formatting logic because customers should see consistent information. Has to adjust it for the 160-character SMS limit, but the core logic is the same.

Mike’s thinking: “There’s some duplication with the email code, but SMS is different enough that abstracting it would be premature. It’s only two notification types.”

Deadline is tomorrow. This ships.

Still nothing catastrophically wrong here. Two types, small duplication, it’s manageable.

Right?

Week 5: User Preferences

Customers start complaining.

“I don’t want SMS notifications.”

“Why am I getting emails for every status change?”

Sarah adds user preferences. Creates a database table. Updates her email handler to check if the user wants that particular notification before sending.

The handler triples in size.

Query the database. Check multiple preference flags. Handle the case where preferences don’t exist yet. Default values. Edge cases.

Sarah’s thinking: “This is getting messy, but the deadline is tomorrow and this works. I’ll refactor it next sprint.”

I cannot tell you how many times I’ve heard “next sprint.”

(Spoiler: next sprint never comes.)

Week 7: Two Ways to Do Everything

Mike needs to add notifications for order cancellations and delivery confirmations.

He realizes hardcoding email bodies isn’t going to scale.

So he builds a template system. Creates a templates directory. Writes a simple renderer. Updates his handlers to load templates, populate data, send.

It’s actually pretty clean.

Meanwhile, Sarah’s handlers still use string formatting. She doesn’t know Mike built a template system. Mike didn’t announce it in Slack. It just… exists now.

The codebase now has two different ways of generating notification content.

Sarah finds out later. Thinks: “I should probably switch to Mike’s templates… but my code is working and I’m slammed with other features.”

And she is. Three new features this sprint. No time to refactor working code.

Week 9: The Third Approach

Emma joins the team.

First task: add Slack notifications for the support team when high-value orders come in.

She opens the notification code. Finds Sarah’s inline approach. Finds Mike’s templates. Neither makes sense for Slack.

Slack needs structured JSON payloads, not formatted text.

So Emma does what any good engineer would do: she creates a “proper solution”.

Notification service class. Methods for each notification type. Handles destination-specific formatting internally. Clean. Testable. Well-designed.

She shows it to the team in standup.

Mike: “That’s nice, but I don’t have time to refactor my SMS code right now. Maybe later.”

Sarah: “I like it, but my code has been running in production for months. If it ain’t broke…”

Emma’s service class gets used for Slack notifications. Nothing else changes.

Now there are three ways to send notifications.

Week 12: The Chaos Compounds

Product wants:

Push notifications for the mobile app
Digest emails (daily order summaries)
Ability to snooze notifications

Three developers. Three features. Same week.

Each one discovers the existing fragmentation. Each one makes their own call.

Developer A tries to extend Sarah’s inline approach. Adds push notification logic directly in the handler.

Developer B uses Mike’s templates but creates a new template format because the existing one doesn’t support digest layouts.

Developer C tries to use Emma’s service class but realizes it doesn’t handle scheduling or snoozing. So they add that logic directly in their handler instead.

The notification preferences table is now being updated by five different code paths.

Each developer added their own columns because they didn’t realize others had added similar fields. One stores preferences as JSON. Another uses boolean columns. Another created a separate preferences table with foreign keys.

I’ve seen this code review happen. Every PR gets approved. Every piece of code works.

Nobody did anything wrong.

And yet.

“Every PR got approved. Every piece of code worked. Nobody did anything wrong. And yet.”

Week 15: Customer Complaints

Support tickets start flooding in.

“I’m getting duplicate notifications.”

“I disabled email but I’m still getting them.”

“I’m not getting notifications at all for important orders.”

Sarah investigates. Opens the codebase.

Six different code paths handle notifications. Some check preferences before sending. Some check during sending. Some don’t check at all because the developer assumed another layer was handling it.

She finds the bug. It’s in her original email handler. The preference check is wrong.

She fixes it. Deploys.

Three other notification types break. They were relying on her buggy behavior.

The team estimate to fix it properly: “We need to stop and refactor everything first, or we’ll just make it worse.”

Management: “We don’t have time for a refactor. Just fix the bugs.”

Week 17: The Template Nightmare

Marketing wants to update email designs. New brand guidelines.

The developer assigned to this opens the codebase.

Templates are everywhere.

Some in a /templates directory. Some hardcoded as strings. Some in the database. Some fetched from an external CMS that one developer integrated without telling anyone.

There’s no single source of truth.

Worse: the data passed to templates is completely inconsistent.

Email templates expect order objects with certain fields. SMS templates expect a flattened structure. Push notifications expect a completely different format.

One design change requires touching dozens of files.

The developer estimates: “Two weeks, maybe three.”

Marketing: “It’s just a design update. How is that two weeks?”

Week 20: Performance Crisis

Black Friday.

The system crashes.

Investigation reveals: notification handlers are opening new database connections for every single notification sent.

Some handlers properly close connections. Some don’t.

Connection pools exhausted. Some handlers retry failed sends immediately and indefinitely, amplifying the problem during the outage. One handler spawns a goroutine for each notification but never limits concurrency.

The server runs out of memory processing a batch of 10,000 order confirmations.

Different developers made different assumptions about error handling.

Some silently swallow errors and log them. Some retry with exponential backoff. Some fail fast. Some store failed notifications in one database table for retry. Others use a different table. One developer integrated a third-party queue system that nobody else knew existed.

Notifications are getting lost between these systems.

I’ve been on calls where the CTO asks: “How many notification systems do we have?”

Nobody can answer.

Week 24: The Audit

Compliance team asks a simple question:

“Can you show us a record of all notifications sent to customer X in the past 90 days?”

The team cannot answer this.

Notification logs are scattered everywhere.

Some handlers log to stdout. Some to files. Some to a database table. Some don’t log at all.

The log formats are completely different. Some include the full message content. Some just log “notification sent” without details. There’s no correlation between the notification and the triggering event.

The auditor asks: “How do you ensure notifications contain required legal disclosures?”

Each template was created independently. Some include required legal text. Some don’t. There’s no centralized enforcement.

I’ve seen this audit happen. Teams spend weeks reconstructing logs manually.

The Breaking Point

VP of Engineering asks for a simple feature:

“Add an unsubscribe link to all emails.”

The team estimates: Three weeks.

The VP is shocked.

“It’s just adding a link. How is that three weeks of work?”

The tech lead explains:

“We have seven different code paths that send emails. Each uses a different templating system. Some render templates on the server. Some fetch them from external systems. Some are hardcoded strings. We need to update each one individually, ensure the unsubscribe logic is consistent across all of them, add tracking for unsubscribe events, update the preferences system to handle unsubscribes properly, and test everything thoroughly because there’s no centralized testing strategy.”

Three weeks. For a link.

The VP asks the obvious question: “How did it get this bad?”

What Went Wrong?

Here’s the thing that kills me about this story.

Nobody made a catastrophically bad decision.

Sarah’s Week 1 implementation was appropriate. Mike’s template system was a reasonable improvement. Emma’s service class was a genuine attempt to bring order.

Every single developer was trying to do good work under deadline pressure.

The problem wasn’t the individual decisions.

It was the absence of a shared architectural vision.

Without clear boundaries and layers, each developer made reasonable local optimizations that created global chaos.

The “I’ll refactor it later” moments never came because there was never a good time to stop feature development.

The “let’s standardize this” conversations happened but never resulted in action because no one had time to migrate existing code.

The codebase evolved organically.

And organic growth without structure doesn’t produce a garden. It produces a weed-infested lot.

“But This Is Just a Communication Problem”

You might be thinking: the real issue was that developers didn’t communicate.

If Sarah and Mike had talked, they wouldn’t have built two different templating systems. If Emma had socialized her service class better, others would have adopted it.

Better standups. Better code reviews. Better documentation. That’s what was missing, not architecture.

This is seductive because it’s partially true.

But here’s why it misses the point: architecture IS communication.

“Architecture IS communication. It’s the most important form of communication for technical decisions.”

It’s the most important form of communication for technical decisions.

Think about what actually happened in the story.

The team DID communicate. Mike showed his template system in code review. Emma presented her service class and got positive feedback. They had a meeting in Week 11 trying to align on standards.

The communication happened.

What didn’t happen was turning those conversations into durable, enforceable decisions.

This is the key difference:

Conversation says “we should probably do X.”

Architecture says “X is how we do things here, and here’s where it lives.”

“Conversation is ephemeral. Architecture is the artifact that persists after the meeting ends.”

When a new developer joins and asks “where should notification logic go?”, the answer shouldn’t require scheduling a meeting or hunting through Slack history.

It should be obvious from looking at the codebase.

Communication without architecture leads to the problem Emma faced. She built something good. People agreed it was good. And then… nothing changed.

Without architectural decisions being explicitly made (“from now on, all notifications go through NotificationService”), the good idea just becomes another option in an increasingly fragmented codebase.

Good communication can prevent chaos. But it can’t survive bad processes.

When developers are under deadline pressure, working on different features, joining the team at different times, communication will have gaps.

Architecture is the safety net for when communication fails.

It’s the shared context that makes it possible to work somewhat independently without creating complete divergence.

So yes, the team in our story could have communicated better.

But the solution isn’t “communicate more.”

It’s “communicate the architecture and make it stick.”

Document where things belong. Make architectural decisions explicit. Enforce them in code review. Build structure that persists beyond any individual conversation.

Because at the end of the day, you can have all the Slack channels and standups and retros you want.

Without a shared architectural foundation, you’re just having the same conversations over and over while the codebase continues to fragment.

What Should Have Happened in Week 1

Sarah should have spent 30 minutes writing this:

# Notification System Architecture

## Where Things Live
- All notification logic → services/notification_service.py
- Templates → templates/ directory (Jinja2 format)
- Preference checks → services/preference_service.py
- Delivery logging → notification_log table

## How to Add a New Notification Type
1. Add template to templates/
2. Add method to NotificationService
3. Log delivery attempt (success or failure)
4. Add tests to test_notification_service.py

## Error Handling
- Retries: 3 attempts with exponential backoff (1s, 2s, 4s)
- Failed sends → dead_letter_queue table
- All errors logged with correlation ID

## Preferences
- Check preferences BEFORE sending (not during)
- Default: all notifications enabled
- Unsubscribe → set all preferences to false

That’s it. 30 minutes of work. Would have saved months of chaos.

<hr class="wp-block-separator has-alpha-channel-

Nobody Knows How to Estimate Software Anymore (And It’s Not Your Fault)

Mon, 16 Feb 2026 01:23:57 +0000

Here’s a pattern I keep seeing (and living):

A feature that would have taken 2-3 weeks gets estimated at “2 days with AI.”

It ships in 4. Sometimes 5.

Not because the AI was slow. Because there are three other “2-day AI projects” running simultaneously. Each one spiraling into bugs, edge cases, and integration issues nobody saw coming. Context-switching between half-finished features, fighting fires, somehow falling behind on all of them.

The AI writes code faster than any human could.

But we’re not shipping faster. We’re drowning.

And here’s the uncomfortable part: we’re doing this to ourselves.

The Promise vs The Reality

You’ve seen the headlines. AI coding tools boost productivity by 39%. Developers are shipping faster than ever. The future is here.

What they don’t tell you is what happens next.

Your manager sees those numbers too. And if AI makes you 39% more productive, why can’t you handle 60% more work? Why are estimates still slipping? Why are bugs still happening?

The math doesn’t add up. And you’re stuck in the middle trying to explain why “AI writes the code” doesn’t mean “features appear instantly.”

Here’s what the data actually shows:

A UC Berkeley study found that AI doesn’t reduce work, it intensifies it. One developer they interviewed said it perfectly: “You thought maybe you’d work less with AI. But you don’t work less. You just work the same amount or even more.”

TechCrunch reported last week: teams adopting AI workflows saw expectations triple, stress triple, but actual productivity only go up by maybe 10%.

And here’s the kicker: a METR study found developers expected AI to speed them up by 24%. In reality? It slowed them down. But they still believed it made them 20% faster.

The gap between perception and reality is dangerous. And most of us are living in it.

The High Expectations Problem

This isn’t just coming from management.

Yes, leadership hears “AI can write massive amounts of code” and expects you to prompt your way through multiple features in no time. First try, maybe second. They don’t understand how AI actually works.

But here’s the honest truth: we don’t either.

I thought I did. I thought “AI writes the code, I review it, we ship it” was the workflow. But that’s not what happens.

What happens is: AI writes the code. I start reviewing it. I find issues. I ask the AI to fix them. It creates new issues. I start another feature while waiting. That one has issues too. Now I’m juggling three half-finished features, each with its own set of AI-generated bugs I’m trying to understand and fix.

The promise was velocity. The reality is fragmentation.

And I keep saying yes to more because “it’s just AI, how hard can it be?” But the cognitive load of reviewing, validating, debugging, and integrating AI code across multiple parallel tracks is crushing.

Every feature looks 80% done. None of them actually ship.

The Estimation Trap

Here’s the confession I don’t want to make: I have no idea how to estimate tasks anymore.

Developers have always struggled with estimation. We underestimate until we get burned enough times to realize “add a simple feature” is never simple when there’s an existing codebase involved.

But AI broke our calibration completely.

A task that used to take 3 days now takes… 2 hours? 4 days? Both? Neither? It depends on:

How well I can describe what I want
How many edge cases the AI misses
How much integration complexity exists
Whether the AI understands the existing patterns
How many iterations it takes to get it right

So now I swing between two extremes:

Under-estimating because “AI will handle it” — then spending 3 days debugging what the AI generated in 20 minutes.

Over-estimating because “who knows what AI will break” — then looking slow when it actually works the first time.

The old rules don’t apply. New ones haven’t emerged. And this isn’t just an academic problem:

Sprint planning becomes guesswork. Roadmaps turn into fiction. Technical debt compounds faster than we can track it. Trust erodes when commitments slip repeatedly.

When someone asks “how long will this take?” the honest answer is often “I don’t know anymore.”

The Hidden Costs Nobody’s Talking About

The expectation problem is obvious once you see it. But there are other traps hiding underneath:

You’re Not Writing Code Anymore. You’re Validating It.

One researcher described it perfectly: “A senior developer with Copilot doesn’t become a code-writing machine. They become a code-validation machine.”

When AI generates 40% more code, you have 40% more code to review. But reviewing AI code is different than reviewing human code. Humans make predictable mistakes. AI makes plausible-sounding nonsense that looks right until you run it.

Context switching between your work and reviewing AI output costs 20-30% of your focus per switch. When you’re juggling multiple AI-started features, you’re switching constantly.

You’re not more productive. You’re just more exhausted.

You Say Yes to Everything

AI makes tasks that used to be “too expensive” feel trivial. So you say yes to things you would have declined or delegated.

“Can you add that dashboard feature?”
“Sure, AI can knock that out.”

“Can you refactor that module?”
“Yeah, should be quick with AI.”

“Can you investigate that performance issue?”
“I’ll have AI profile it.”

Harvard Business Review calls this work intensification: AI doesn’t reduce your workload, it makes you take on more.

You’re not automating your way to free time. You’re automating your way to more commitments.

The Quality-Speed Death Spiral

Here’s how it compounds:

AI gives you an initial productivity surge
That surge creates expectations for speed
Speed pressure leads to cutting corners on review
Lower quality creates more bugs
More bugs mean more debugging and rework
Debugging takes longer because you didn’t write the code
You fall behind, pressure increases, quality drops further

The Berkeley researchers warned: “The productivity surge enjoyed at the beginning can give way to lower quality work, turnover, and other problems.”

This is happening right now across teams. Features ship that “work,” but the developers don’t fully understand how. When they break, debugging becomes an archaeology project through code nobody wrote and barely reviewed. That’s not faster. That’s deferred pain.

What This Actually Feels Like

A software engineer named Siddhant Khare wrote about “AI fatigue” last week. It resonated with me immediately because it’s real and nobody talks about it.

AI-era burnout doesn’t look like working 80-hour weeks. It looks like:

Decision fatigue from validating endless AI outputs. Every line might be wrong. Every function might have a subtle bug. You can’t just skim.

Cognitive load from juggling multiple AI-started initiatives. Each one 80% done. None actually shipping.

Imposter syndrome when you can’t tell if you’re productive or just busy. You wrote 3,000 lines this week. Zero features shipped. Are you slow? Or is the process broken?

Anxiety from commitments you can’t estimate. You said 2 days. It’s been 4. The AI generated the code in 20 minutes and you’ve been debugging it ever since.

Guilt for not keeping up. Everyone else seems to be shipping faster with AI. Why aren’t you?

The research shows that some developers see burnout risk drop 17% with AI — but only if their workload doesn’t increase to fill the gap.

In practice? Workload always increases.

The Team Lead’s Nightmare

If estimating one AI-assisted task is this chaotic, imagine coordinating an entire team.

You’re trying to plan a sprint. Every developer gives you an estimate. Half of them are wildly optimistic because “AI will handle it.” The other half are padding heavily because they’ve been burned.

You don’t know which estimates to trust. You don’t know how to aggregate them into a roadmap. You don’t know how to explain to stakeholders why the team that just adopted “productivity-boosting AI tools” is still missing deadlines.

And when the sprint ends? Half the stories are “80% done.” A quarter shipped but with bugs. The rest are stuck in AI-generated complexity no one fully understands.

Tech leads are stuck in the middle. Can’t estimate their own AI-assisted work. Somehow supposed to help the team estimate theirs.

Sprint planning feels like collective guessing. Retrospectives turn into “we don’t know what went wrong, the AI just… took longer than expected.”

The only solution I’ve found is the boring one: go back to basics.

Estimate anyway. Even if it’s totally wrong.
Run retrospectives. Understand what actually happened.
Repeat every cycle. Gather data.
Adjust future estimates based on reality, not hope.

It’s unglamorous. It’s slow. But it’s the only path I see to understanding our true capacity with AI.

You can’t optimize what you don’t measure. And right now, most teams aren’t measuring anything except “we’re using AI, we should be faster.”

After enough cycles, patterns emerge:

AI features that touch legacy code take 3x longer than expected
Net-new features hit estimates more reliably
Code review adds 40% to any AI-heavy story
Integration work still takes the same time regardless of AI

None of this is in the “AI boosts productivity 39%” headline. But it’s the reality of coordinating a team in the AI era.

The boring strategies we’ve always used — estimate, measure, learn, adjust — they still work. They’re just slower to calibrate now because the variables changed.

What I’m Trying (Not Prescribing)

I don’t have this figured out. Nobody does yet. But here’s what’s helping in my experience:

The One-Thing Rule

Stop saying yes to multiple simultaneous AI features. One thing from start to shipped before starting the next.

Does it feel slower? Yes.
Do you actually ship more? Also yes.

Multiple AI-started initiatives feel like progress until nothing’s actually done. Finishing one thing beats starting five.

Honest Estimates

When someone asks “how long will this take?” stop giving the optimistic AI-boosted number.

Instead: “AI might generate it in an hour. Integration and debugging might take 3 days. Estimate 4 days to be safe.”

It feels slow. But estimates stop slipping constantly. And trust improves.

The Validation Budget

Timebox AI code review. If you can’t fully understand and validate what the AI built in the time it would have taken to write it yourself, don’t use the AI code.

Sounds counterintuitive. But reviewing 800 lines of AI code you don’t understand for 6 hours defeats the purpose. Sometimes writing 200 lines yourself in 4 hours is actually faster.

Measuring What Matters

Stop tracking lines of code or features started. Track instead:

Features actually in production
Bugs introduced per feature
Time from “start” to “shipped” (not “AI generated code”)
Team stress level (are people sleeping okay?)

The numbers are uncomfortable. But they’re honest.

Using Speed for Quality, Not Quantity

When AI genuinely saves time, spend that time on:

Better tests
Clearer documentation
Paying down technical debt
Deeper thinking on architecture

Not just “more features.”

The productivity gain is real. The question is: who captures it? If it all goes to “more output for the same salary,” you’re on a treadmill. If some goes to making work better and more sustainable, everyone might actually benefit.

At the Team Level: The Data Discipline

For tech leads and managers, the same boring-but-effective cycle applies:

Estimate — Even when it feels like guessing. Get the team’s best guess on record.
Measure — Track actual time, not AI generation time. Start to shipped, not start to “AI wrote code.”
Retrospect — What took longer than expected? What patterns are emerging?
Adjust — Use the data. If AI stories touching legacy code are consistently 3x estimates, factor that in next sprint.

After 4-5 cycles, you start seeing your team’s actual capacity with AI. Not the theoretical 39% boost. The real number.

It’s slower than anyone wants. But it’s the only path to honest planning.

The Uncomfortable Question

Here’s what I keep coming back to:

The 39% productivity gain might be real. But who’s capturing it?

Your company captures it as more output for the same salary.
Your manager captures it as more ambitious roadmaps.
The market captures it as higher expectations.

You capture… what? More stress? More context-switching? More debugging code you didn’t write?

Unless you actively defend your boundaries, AI productivity tools become productivity traps — a treadmill that speeds up but never lets you off.

I don’t want to sound cynical. AI is genuinely powerful. I use it every day. But the default path is work intensification, not work reduction. And if you don’t choose differently, the default will choose for you.

A Different Path

What if AI augmentation wasn’t about doing more? What if it was about doing better?

What if productivity gains went toward:

Deeper thinking on hard problems
Mentoring junior developers
Paying down technical debt
Building more resilient systems
Actually shipping polished features instead of half-finished experiments
Sustainable pace instead of constant sprinting

The technology is powerful. The question is: who decides what that power is for?

Right now, the default answer is “more output.” But you can choose differently.

You can say no to the fifth simultaneous initiative.
You can give honest estimates instead of optimistic ones.
You can spend AI-gained time on quality instead of quantity.
You can protect your boundaries instead of filling every efficiency gain with new commitments.

The 39% productivity trap is only a trap if you don’t see it coming.

Now you do.

What’s Next

This is still being figured out across the industry. Some weeks teams ship fast and feel great. Other weeks they’re drowning in half-finished AI features and wondering what went wrong.

But patterns are emerging. Data is being gathered. Teams are learning to say no more often. And slowly, the industry is learning to use AI as a tool for better work, not just more work.

If you’re feeling this too — the expectations, the estimation chaos, the validation treadmill — you’re not slow. You’re not behind. The system is broken, and you’re just the first to notice.

The question is: what are you going to do about it?

If this resonated with you, I’d love to hear your experience. Are you in the productivity trap too? What are you trying? Find me on LinkedIn.

Further Reading:

TechCrunch: “The first signs of burnout are coming from the people who embrace AI the most” (Feb 2026)
Harvard Business Review: “AI Doesn’t Reduce Work—It Intensifies It” (Feb 2026)
Fortune: “AI is having the opposite effect it was supposed to” (Feb 2026)
METR: “Measuring the Impact of Early-2025 AI on Developer Productivity”
Business Insider: “AI fatigue is real and nobody talks about it” (Feb 2026)

The post Nobody Knows How to Estimate Software Anymore (And It’s Not Your Fault) appeared first on sudoish.

The Review Bottleneck: Why AI Explanations Are Making Us Trust Less, Not More

Fri, 13 Feb 2026 21:02:40 +0000

Last week I spent 3 hours reviewing code that took 20 minutes to write.

The AI was faster. The review wasn’t.

And I’m starting to realize: that’s the problem.

“Less coding, more engineering.”

I keep hearing this phrase everywhere. The idea is simple: AI handles the coding, so developers focus on the higher-level work. The engineering. The architecture. The review.

But here’s what nobody’s talking about: AI isn’t just writing the code anymore. It’s reviewing it too.

And the paradox is obvious once you see it: AI generates code faster, but reviewing it takes longer than ever.

Here’s what those 3 hours looked like:

I read through 300 lines of code carefully. Checked the tests. Verified the logic flow. Examined edge cases.

But that was only the first hour.

The next two hours? Reading AI-generated explanations. Reviewing the AI code reviewer’s feedback. Cross-referencing the AI’s architectural justifications with the actual implementation. Trying to reconcile conflicting suggestions from different AI systems.

By the end, I understood the code. But I’d spent more time processing AI commentary than reviewing actual logic.

And here’s what bothered me: I see people in the industry are approving similar PRs in 20 minutes.

Are they reading all of this? Or are they skimming the AI explanations and trusting by default?

I’m pretty sure it’s the second one.

This isn’t about being thorough versus lazy. It’s a recognition of something shifting.

300 lines of actual code
1,200 words of AI-generated explanation
800 words of AI code review feedback
15 inline comments from the AI about trade-offs and alternatives

I had more documentation to review than code.

300 lines of actual implementation
2,000+ words of AI-generated commentary

The code was the easy part. The cognitive load came from synthesizing multiple AI perspectives, each confident, each reasonable-sounding, some subtly contradicting each other.

The tests passed. The linting passed. The AI explanations sounded reasonable. The AI reviewer’s concerns seemed addressed.

So I trusted the process and moved on.

And that’s becoming the norm.

I’m not alone.

At Anthropic—the company building Claude—engineers are generating 2,000 to 3,000 line pull requests regularly. Mike Krieger, their Chief Product Officer, openly admits: “pretty much 100%” of their code is now AI-generated.

And they’re using Claude to review it too.

Boris Cherny, head of Anthropic’s Claude Code team, hasn’t written a single line of code in over two months. He shipped 22 pull requests in one day, 27 the next.

“Each one 100% written by Claude.”

This isn’t the future. It’s happening right now, at the companies building the AI tools we’re all using.

The Confidence Trap

Code reviews were already hard. They required skill, domain knowledge, and patience.

Now multiply that by the sheer volume AI generates.

But volume isn’t even the real issue.

The real issue is that AI writes confident code. It comes with detailed explanations. Trade-off analysis. References. Architecture justifications.

Enough well-articulated reasoning to make everything sound sensible.

When you look at a 500-line PR with a 2,000-word explanation of why every decision was made, the cognitive load is enormous.

You can dig in and verify every claim.

Or you can trust that the explanation sounds reasonable and move on.

Most developers are choosing “move on.”

Here’s where we are:

Claude Code and Codex are generating code at unprecedented scale. 46% of developers’ code is now AI-written across major tools like Claude Code, Codex, and GitHub Copilot.

84% of developers use AI coding tools regularly.

And here’s the kicker: while AI generates nearly half our code, only 30% of AI-suggested code actually gets accepted.

The rest gets rejected during review—or should get rejected.

Then We Added AI Code Review

So teams did the obvious thing: bring in AI code review tools.

Now every PR has:

The AI-generated code (500 lines)
The AI’s explanation of what it built and why (2,000 words)
The AI reviewer’s analysis (another 1,500 words)
Sometimes multiple AI reviewers, each with their own opinions

You’re staring at 4,000+ words of confident, reasonable-sounding explanations from multiple AI systems.

All of it well-structured. All of it articulate. Much of it contradicting itself in subtle ways.

And you’re supposed to synthesize all of this, make a judgment call, and approve or reject.

What actually happens?

You skim the AI’s explanation. You skim the AI reviewer’s comments. If they roughly agree and the tests pass, you approve it.

The AI’s confidence became your confidence by default.

Research confirms what we all feel: AI-generated code creates 1.7x more issues than human-written code.

Unclear naming. Mismatched terminology. Generic identifiers everywhere.

All of it increasing cognitive load for reviewers.

And here’s the kicker: all of it explained so confidently you don’t question it.

This is what researchers call “automation bias”—our tendency to accept answers from automated systems, even when we encounter contradictory information.

We’re not carefully evaluating the code. We’re trusting that the volume of explanation equals correctness.

More Explanation ≠ More Understanding

The paradox is obvious once you see it:

Adding AI code reviewers didn’t make reviews better. It made them worse.

Not because the AI reviewers are bad. But because the sheer volume of explanation—from the writer AI, from the reviewer AI, sometimes from multiple reviewer AIs—has become impossible to actually process.

We traded one problem (not enough context) for another (too much confident noise).

And the human reviewer, the supposed quality gate, is now just the person who clicks “Approve” after skimming thousands of words they don’t have time to verify.

The bottleneck isn’t writing code anymore.

It’s not even reviewing code.

It’s trusting code we don’t fully understand because we’re drowning in explanations that sound reasonable but are too expensive to verify.

Even OpenAI acknowledges this in their Codex documentation: “It still remains essential for users to manually review and validate all agent-generated code.”

But are we actually doing that?

The evidence suggests no.

Wait. See What Just Happened?

I need to be honest with you.

I almost did the exact same thing to you.

I almost buried this post in citations.

16 footnotes. Statistics every other paragraph. Research from Anthropic, OpenAI, arXiv, CodeRabbit, Qodo. All credible. All well-sourced. All making the same point.

And if you’re like most readers, you would have skimmed them. Trusted that they said what I claimed. Moved on.

That’s exactly what we’re doing with code reviews.

The volume of explanation—even when accurate—becomes its own problem. Too many words. Too much confidence. Not enough time to verify.

So we trust by default.

What I’m Trying

I don’t have this solved. But here’s what’s working for me:

The 30-minute rule – If I can’t understand the PR in 30 minutes of focused review, it’s too big. Send it back or break it down.

No AI reviewer without human review – AI review is a supplement, not a replacement. I still need to read the actual code, not just the summary.

The explain-it test – If I can’t explain the core logic to someone else, I don’t approve it. Knowing “the tests passed” isn’t good enough.

Does this slow me down? Yes.

Does it help? I think so.

But I’m also watching my team ship faster by trusting more. And I don’t know if I’m being careful or just stubborn.

Where This Leaves Us

I’m caught in the same trap.

I want to ship faster. But I also want to understand what I’m shipping.

And the current tools make both feel impossible at the same time.

Some days I slow down and review everything carefully. Other days I skim and trust.

And I’m not sure which approach is right anymore.

Anthropic’s Dario Amodei predicts the industry may be “just six to twelve months away from AI handling most or all of software engineering work from start to finish.”

25% of Google’s code is already AI-assisted.

30% of Microsoft’s code is AI-generated.

These aren’t small experiments. This is how we’re building software now.

But here’s what we’re not saying out loud:

We’ve replaced code we wrote and didn’t fully understand with code AI wrote and we definitely don’t understand.

We’re not talking about this problem honestly enough.

The “less coding, more engineering” narrative assumes we’re still doing the review work.

We’re not.

We’re skimming AI-generated justifications and hoping for the best.

Maybe that’s fine. Maybe the tests are good enough. Maybe AI review plus AI generation actually works.

But we should stop pretending we’re still doing the review work.

Because “less coding, more engineering” sounds great until you realize:

We’re not doing more engineering.

We’re doing more trusting.

So here’s my question:

Are you actually reviewing AI code? Or are you just hoping the explanation is right?

Because if it’s the second one—and the data suggests it is—we need to start talking about what comes next.

The quality gate we automated away isn’t coming back. We need to figure out what replaces it.

Next up: I’m going to share how I’m breaking down AI-generated features into bite-sized review sessions that force comprehension instead of trust. It’s slower. It’s deliberate. And it might be the only way to stay honest about what we’re shipping.

References & Further Reading

Key Sources:

Fortune: “Top engineers at Anthropic, OpenAI say AI now writes 100% of their code” – Mike Krieger and Boris Cherny interviews, January 2026
GitHub Copilot Statistics 2026 – 46% of code AI-generated
CodeRabbit: “AI code creates 1.7x more issues” – Cognitive load study, 2025
Index.dev: Developer Productivity Statistics 2026 – 84% adoption, 30% acceptance rate
OpenAI: Using Codex with ChatGPT – Manual review guidance
Springer: Automation bias in human–AI collaboration – AI & Society, July 2025

The post The Review Bottleneck: Why AI Explanations Are Making Us Trust Less, Not More appeared first on sudoish.

Are We Still Developers? The Hidden Cost of Vibe Coding

Mon, 09 Feb 2026 04:22:59 +0000

I generated 847 lines of production code in 12 minutes.

Not pseudocode. Not a prototype. Real, working Python with tests, error handling, API integration, and it works well. I described what I wanted to an AI agent, went to grab coffee, came back, and it was done.

It felt incredible. Like unlocking god mode. Why would I ever go back to writing code line by line?

The Promise & The Reality

This is the promise of AI-centric development tools like Zencoder, vibe-kanban, and even parts of Cursor. Steve Yegge calls it “vibe coding”: stop micromanaging, trust the AI, let it scaffold entire features while you focus on the big picture. And when you see it work, it’s intoxicating.

But here’s what happened next.

I had to review those 847 lines. Every function. Every edge case. Every assumption the AI made about my requirements. Did it handle validation correctly? Is this maintainable? Did it miss something subtle about the business logic?

The review took longer than writing it would have.

And I still wasn’t confident. So I asked a different AI to review the first AI’s code. It found some issues. I fixed them. But now I’m reviewing AI-generated fixes to AI-generated code, and I’m three layers deep in a review process that feels more like managing a team of junior developers than writing software.

Then comes the PR. Do I ask my teammates to review 847 lines of AI code? They’ll either spend hours on it (and resent me) or run it through AI themselves (and we’re all just trusting machines at that point).

The Identity Question

So I have to ask: what does this make us as developers?

If AI writes the code and AI reviews the code, and we’re just approving diffs we don’t fully understand… are we developers anymore? Or are we product managers for code we didn’t write?

Maybe that’s fine. Maybe AI is good enough now that we should embrace it.

But I don’t think it is. Not yet. I find issues constantly: bugs the AI missed, patterns it didn’t understand, edge cases it overlooked. And the “big bang” feature implementations don’t feel right to me. I still value ensuring the AI is building the right thing according to my understanding of the problem. And the only way to do that is to review in detail, stay close to the code, and actually understand what’s being built.

My Journey Through the Landscape

I’ve been a Vim user for years. Not the “I use Vim btw” meme kind. The “my fingers know hjkl better than WASD” kind. The muscle memory runs deep. So when AI coding assistants exploded onto the scene, I had a choice: migrate to VS Code like everyone else, or figure out how to make AI work in my world.

Let’s be clear: I didn’t stick with Vim out of stubbornness. I explored the alternatives. I keep exploring them.

Cursor: Too Distant

I’ve tried Cursor. It’s impressive: genuinely AI-first, with inline suggestions and chat that feels magical. But here’s the problem: it makes you too distant from the code. You’re directing an AI that’s directing the editor. There’s a layer of abstraction I don’t trust yet. I want my hands closer to the metal.

Zed: Doesn’t Fit My Workflow

I tried Zed. Better balance. It’s code-centric with AI tools bolted on the side: you choose when to invoke them. I liked that. But Zed expects you to work on one project at a time. That breaks my workflow immediately. I live in tmux with 3-4 projects open, constantly switching contexts, piping output from one terminal to another. Zed doesn’t fit that reality.

Zencoder & vibe-kanban: Even More Distant

Then I went to the other extreme: full AI-centric tools like vibe-kanban and Zencoder. I was motivated to try this route after reading Steve Yegge’s writings on vibe coding. The idea is compelling: stop micromanaging the AI, trust the vibes, let it scaffold entire features while you focus on the big picture. So I gave it an honest shot.

These tools are wild. You describe what you want, and they scaffold entire features, write tests, integrate APIs. It feels like having a senior dev in a box. Zencoder especially caught my attention. You feel powerful. You ship fast.

But here’s the catch: you’re absurdly distant from the code.

AI writes it. AI organizes it. You review diffs like a manager reviewing PRs. And I don’t trust AI that much yet. Every line it writes, I have to re-review. Does it meet standards? Is it maintainable? Did it miss an edge case? The review overhead is real.

What I realized: I still need to review code in detail and ensure features are going in the right direction. The “trust the vibes” approach sounds liberating, but in practice, I’m doing more cognitive work reviewing after the fact than I would have supervising during development.

The Solution: Bite-Sized Pair Programming

So I found a middle ground: bite-sized pair programming with AI. The AI does most of the coding. I supervise and keep it on track. I course-correct in real time instead of reviewing a massive diff later. And the best way I’ve found to do that is still Neovim + tmux: AI in one pane, code in another, constant back-and-forth.

I don’t write code the same way I used to. I used to open a file, think through the problem, and type. Now? I spin up a worktree, open an AI in a terminal pane, and direct the solution instead of typing it character by character. But I stay close. I supervise. I course-correct in real time.

The AI does the heavy lifting. I do the thinking. It’s not full vibe coding. It’s not solo coding either. It’s collaborative, with me staying close enough to catch problems early. The tools are different. The medium is the same: the terminal.

AI in the Terminal: Multiple Tools, One Workflow

The real shift wasn’t about finding one perfect plugin. It was about building a workflow that lets me use whatever AI tool fits the task without leaving the terminal.

For a while, I experimented with different approaches: Claude Code in a split buffer, Codex in a tmux pane, jumping between terminal windows to manage different tools manually. I wasn’t married to any particular setup.

More recently, I’ve found somewhat of a sweet spot: I use sidekick.nvim as my interface layer. It gives me the flexibility to switch between different AI agents when I want to. But in practice? I mostly default to Claude Code. Its rules and configuration are pretty robust right now, plus my company pays for it, so why not use it?

That’s the real advantage of the terminal workflow: the flexibility is there when you need it. Want to test a new model? Swap it in. Want a second opinion on code? Switch agents mid-task. But you’re not forced to constantly context-switch. You can settle into what works and only switch when it makes sense.

And here’s a workflow trick I’ve been using: implement a feature with one AI tool, then review or test it with a different one. You get a less biased second opinion. If Model A wrote the code and Model B flags the same issues you’re concerned about, you know it’s real. If Model B says “looks good,” you have more confidence. It’s like pair programming, but the second programmer is a completely different intelligence.

The “best” AI model changes constantly. Claude Code dominates today, but that changes by the hour. Being locked into one tool means you’re always playing catch-up. In the terminal, switching is trivial.

Why the Terminal Wins

Neovim scored 83% in StackOverflow’s 2024 Developer Survey as the most admired IDE, even though VS Code is the most used at 59%. That gap tells you something. People who use Vim don’t just tolerate it. They love it. And it’s not Stockholm syndrome.

Here’s what keeps me here.

Hands on the Keyboard

When my hands never leave the keyboard, I stay in flow. Every time I reach for the mouse, there’s a micro-decision: where’s the cursor? What am I clicking? Did I miss? Those interruptions compound. Not just in seconds, but in mental overhead.

Want to find a file? <leader>sf brings up Telescope. Search across everything? <leader>sg for live grep. Navigate between Vim splits, tmux panes, or even tmux windows? Ctrl+h/j/k/l handles it all seamlessly. Start a new task with a worktree and AI ready? <leader>at. Toggle a floating terminal? <leader>;.

No mouse. No sidebars. No menu hunting. Just muscle memory.

The AI tools I use (Claude Code, Codex, OpenCode) fit into this. I don’t context-switch to a browser or separate app. I invoke them in a split pane with a keybind. Everything stays in one place.

Speed isn’t about typing fast. It’s about never stopping.

The Terminal is a Toolkit

The terminal isn’t one tool. It’s composable. Want to process JSON from an API? Pipe it to jq. Transform file paths? sed or awk. Run a command on 50 files? find | xargs. Monitor logs while coding? tmux split with tail -f.

When you add AI to this composability, things get wild.

I can prompt Claude Code in one pane, watch it write code in another, pipe the output through a test runner, grep the results, and feed errors back into the AI. All without leaving the terminal. All scriptable. All reproducible.

Cursor can’t do that. You can’t pipe Cursor’s output through grep. You can’t script it to run in a loop. It’s a black box. The terminal is Lego blocks, and AI is just another piece.

Performance You Actually Feel

VS Code and Cursor are Electron apps. They’re running a full Chromium browser under the hood. Neovim is written in C. It opens instantly, uses around 50MB of RAM, and never lags.

When I spin up 10 tmux tabs with Neovim and AI tools, my system barely blinks. Try opening 10 VS Code windows and listen to your fan scream.

I juggle 5 to 10 worktrees at any given time. Each one is a separate environment. If each took 500MB of RAM and 3 seconds to load, my workflow would fall apart. Neovim and tmux? Instant, lightweight, snappy.

My Setup is Code

My entire development environment is 600 lines of dotfiles in a git repo. New machine? Clone it, run a script, and I’m back up in two minutes. Same keybinds, same plugins, same aliases, same AI integrations.

GUI tools let you sync settings, but you’re at the mercy of their config systems. With terminal tools, the setup is code. You can version it, diff it, review it, share it. I can recreate my entire workflow on a fresh VM faster than VS Code can install.

These Tools Have Staying Power

Vim came out in 1991. Neovim in 2014. tmux in 2007. They’ve outlived programming languages, frameworks, companies. They’ll outlive Cursor. They’ll outlive Zed. They might outlive JavaScript.

The muscle memory I’m building, the keybinds, the workflow patterns: they’ll be relevant in 10 years. Will Cursor? Maybe. Probably not. Learning Vim is an investment that compounds. GUI tools are a bet on a company staying solvent.

The Control Gradient

Here’s how I think about the spectrum:

Full Control (Traditional Vim)
You write every character. You think through every problem. Slow, but you know exactly what’s happening.

AI-Assisted (My Current Setup)
You direct the solution. AI accelerates execution. You stay close to the code. You review as it’s built, not after. You can do manual trivial actions where pertinent instead of asking everything to the agent.

AI-First (Cursor, Zed)
AI suggests, you accept/reject. Fast, but you’re reacting more than creating.

AI-Centric (Zencoder, vibe-kanban)
AI builds, you review diffs. Fastest, but you’re a product manager for code you didn’t write.

Right now, AI-assisted is the sweet spot. I get speed without losing control. I stay in my flow. I trust the output because I was there while it was written.

But I’ll be honest: this might not last.

AI is getting scary good at both writing and reviewing code. It’s catching bugs I miss. It’s flagging patterns I overlook. If AI review becomes as reliable as human review, the argument for staying hands-on gets weaker.

We might be transitioning to AI-centric whether we like it or not. The question is: how long do I have before “staying close to the code” becomes nostalgia instead of pragmatism?

For now, I’m staying in the terminal. But I’m watching.

The Honest Uncertainty

This workflow makes me feel in control. I know where my code is, how it got there, and what’s happening at every step. I’m not watching an AI build something in the background and hoping it got it right. I’m directing it, reviewing as it goes, staying close to the work.

That control matters. For now.

But I’d be lying if I said I’m confident this is the future. AI is getting better at an absurd pace. It’s already catching bugs I miss. It’s writing code that would take me hours in minutes. It’s reviewing my work and finding patterns I overlooked.

At some point, the argument for staying hands-on stops being pragmatic and starts being nostalgic. Maybe we’re already there and I just don’t want to admit it.

I keep testing the AI-first tools. Zencoder, vibe-kanban, Cursor. Not because I think they’re worse, but because I want to know when the terminal workflow stops being the smart choice and starts being stubbornness.

Maybe that happens next week. Maybe it already happened and I’m just slow to see it. AI-centric development might not be a distant future. It might be now, and I’m still clinging to a workflow that makes me comfortable.

For today, I’m staying in the terminal. It’s faster for me. It fits how I think. It keeps me close to the code in a way that feels right.

But tomorrow? Who knows.

The terminal-centric workflow wins for me right now. But I’m watching the gap close. And when it does, I’ll probably switch. Not because I want to, but because it’ll be the obvious move.

Until then, I’ll keep hitting <leader>at and letting the AI do the heavy lifting while I stay at the wheel.

The post Are We Still Developers? The Hidden Cost of Vibe Coding appeared first on sudoish.

The Developer Identity Crisis

Mon, 09 Feb 2026 04:22:47 +0000

I keep seeing variations of this pitch everywhere:

“A bug report hits Jira at 3 AM? Your autonomous agent wakes up, reproduces it, writes the fix, and opens the PR before your alarm goes off.”

That’s from Zencoder’s marketing site. But it’s not just marketing anymore, developers are actually doing this. They’re using tools like Zencoder, Claude code, Openclaw, and others to delegate entire features or bug fixes to AI agents that run autonomously while they sleep.

The workflow is straightforward: assign a GitHub issue to the agent, let it work overnight in a sandboxed environment, wake up to a pull request with passing tests, review the diff, merge it.

The tests pass. The code works. They ship it.

And here’s the part that keeps me up at night: many of them admit they don’t fully understand every implementation detail. They review for correctness and patterns, but not line-by-line comprehension. And they’re shipping faster because of it.

I’ve been thinking about this for weeks. Because I can’t do that. Not yet.

My Workflow Isn’t There Yet

I use AI constantly. Claude Code and orchestrators like OpenClaw, they’ve transformed how I work. I can spin up features that would have taken days in a fraction of the time. The productivity gains are real.

But I still review everything. I still read the diffs. I still make sure I understand what went into the codebase before I approve it. I don’t merge code I haven’t checked.

And here’s the uncomfortable part: I’m starting to wonder if that makes me slow.

Because I’m watching people who don’t review everything. They’re shipping faster. They’re building more. And their code… works. Their products ship. Their companies grow.

The question that keeps me up at night isn’t “can AI code?” anymore. It’s: how much can I trust it before my caution becomes a liability?

The Job Changed Underneath Us

If you’ve been coding for more than a few years, you’ve felt it. The ground shifted. What we do day-to-day looks fundamentally different than it did even 18 months ago.

We used to write code. Now we orchestrate AI agents that write code.

We used to debug line by line. Now we describe the bug and let the agent fix it.

We used to refactor carefully. Now we prompt for a rewrite and evaluate the output.

The transformation isn’t subtle anymore. AI agent tools crossed some threshold. They’re not assistants anymore, they’re doing the actual work.

And here’s what nobody wants to say out loud: they’re often better at it than we are. Faster, definitely. More thorough in edge cases. Less prone to the lazy shortcuts we take when we’re tired.

The role of “software developer” didn’t disappear. It just became something else entirely. We’re now:

Task organizers — Breaking down requirements into agent-friendly chunks
Configuration engineers — Building rules, skills, and context for AI systems
Quality evaluators — Reviewing output for correctness, not writing it ourselves
Visibility champions — Advocating for our work because “just coding” is invisible now

If you’re a developer who just wants to code in peace, I have bad news for you: that job is disappearing.

The Pioneers Are Already There

I’m not imagining this shift. Some of the sharpest minds in our industry are actively building for a future where human code review might be optional and their work reveals just how far the transformation has already gone.

Steve Yegge’s Gas Town: The Industrial Coding Factory

Steve Yegge—the legendary blogger who gave us classics like “Stevey’s Google Platforms Rant”—recently launched Gas Town, what he calls “a new take on the IDE for 2026.” It’s not an IDE in any traditional sense. It’s an orchestrator for running dozens of Claude Code instances simultaneously.

In his words: “Gas Town is an industrialized coding factory manned by superintelligent robot chimps.”

He describes an 8-stage evolution of the AI-assisted developer, from basic code completions all the way to running 10+ agents at once. If you’re not at stage 6 or 7? “You will not be able to use Gas Town. You aren’t ready yet.”

Yegge also created Beads, a persistent memory system for coding agents. Because when you’re running that many agents, you need infrastructure just to keep track of what they know. He’s literally building Kubernetes for AI coders.

The pattern he describes: Prompt → Sleep → Evaluate → Keep or Toss. Work becomes “an uncountable substance that you sling around freely, like slopping shiny fish into wooden barrels at the docks.”

That’s not coding as we knew it. That’s something else entirely. And Yegge’s doing it right now.

ThePrimeagen’s 99: The Neovim Purist’s Answer

On the other end of the spectrum, ThePrimeagen, known for his Neovim evangelism, launched 99, which he describes as “the AI agent that Neovim deserves.”

His philosophy is different from the full-orchestration approach. 99 is built for developers “who don’t have skill issues”, those people who want AI integrated into their existing workflow, not replacing it. It’s about restricted AI interactions: fill in a function, handle a visual selection, stop when you want.

The interesting part? Even ThePrimeagen, arguably one of the most skilled traditional developers in the content space, is building AI tooling. He’s not fighting the wave; he’s figuring out how to ride it on his own terms.

These aren’t fringe experiments. These are serious developers building serious tools because they see what’s coming.

Caught in the Middle

So where does that leave people like me?

I see where this is going. I believe the future probably shifts heavily toward these “prompt and trust” workflows. The economics are too compelling. The speed advantages are too real. Companies will gravitate toward developers who ship faster, and right now, that means developers who trust AI more.

But I’m not there yet. And I’m honestly not sure if my reluctance is:

Wisdom: A healthy caution born from experience with software that breaks in subtle ways
Ego: An attachment to feeling like a “real programmer” who understands their code
Fear: Discomfort with a world where my hard-won skills matter less

Maybe it’s all three.

The honest truth is: I don’t fully trust AI-generated code yet. Not because I’ve seen it fail catastrophically. But because the few times I have caught issues, they were subtle. The kind of bugs that pass tests but cause problems in production. The kind that make you question everything you didn’t review carefully.

And yet… those catches are getting rarer. The AI is getting better. Every month the code quality improves, the edge cases get handled more gracefully, the architecture decisions get more sensible.

At what point does my reviewing become theater? At what point am I just going through the motions because it feels wrong not to, even though I’m not actually catching anything?

I don’t have an answer.

The Uncomfortable Truths We’re Not Talking About

Whether you’re in the “trust fully” camp or the “review everything” camp, some things are happening to all of us.

Skill Atrophy is Real

I’ve noticed it in myself. There are language features I used to know cold that I now… don’t. Not because I forgot them entirely, but because I haven’t actually typed them as often. The AI does it.

When I do need to write code without AI assistance, I’m slower. Rustier. More likely to look things up that used to be automatic.

Is this a problem? I don’t know. Maybe these skills don’t matter anymore. Maybe they do. But either way, they’re fading.

The Carelessness Creep

Even when I review code, I’ve caught myself being less thorough than I used to be. When the AI can regenerate something in seconds, the stakes for any individual piece feel lower. Made a mistake? Trash it and re-prompt.

This creeping carelessness scares me. Not because every line needs to be perfect, but because I’ve noticed myself letting things slide that I wouldn’t have before. Small things. Subtle things. The kind of issues that compound.

Code Review Culture is Fragmenting

Here’s where it gets really weird: people are using AI to review code too.

On one hand, this is powerful. AI can catch patterns and issues that humans miss. But on the other hand… we’re now in a loop where AI writes code and AI reviews code and humans just glance at both and click approve.

What happens when we stop deeply understanding the systems we’re building? When code becomes something we orchestrate but don’t really know?

The Disposable Code Question

Maybe code quality just doesn’t matter the way it used to.

If AI can rewrite a module in 30 seconds, why spend hours making it elegant? Why obsess over structure, readability, maintainability? Just make it work. When it breaks or needs to change, throw it away and regenerate it.

This feels wrong to me. But I can’t articulate exactly why. Maybe I’m just attached to an old way of working. Maybe “good code” was always just a means to an end, and now there’s a faster means.

Maybe code doesn’t need to be human-readable anymore. Maybe it just needs to be AI-readable. And maybe that’s fine.

I genuinely don’t know.

The Paradox: Embrace or Fall Behind

Here’s the impossible choice: embrace AI coding fully and potentially lose something essential, or maintain your review discipline and risk becoming irrelevant.

If you don’t use these tools you’re objectively slower than colleagues who trust more and verify less. You deliver less. You look less productive. In a world where companies are cutting costs and measuring output, that’s not sustainable.

But if you do embrace them fully, you risk becoming dependent. Losing skills. Becoming someone who can’t actually code anymore, just prompt.

I’m trying to find a middle path. Use AI heavily for generation, but maintain understanding. Trust but verify. It’s uncomfortable. It might not be sustainable. But it’s where I am right now.

And here’s the kicker: the job now requires something that coding alone never did: visibility.

It’s not enough to do good work. You have to be seen doing it. You have to advocate. Document. Communicate impact. Build relationships. The IC who just crushes code tickets in silence? That person is becoming a liability, because from the outside, it’s unclear what AI could or couldn’t do in their place.

What Even Is a Developer Anymore?

Here’s where I diverge from the panic.

A lot of developers are having an identity crisis because “AI can code now.” But honestly? I always thought being a developer was about more than writing code.

The job was never just about typing syntax. It was always about:

Knowing what to build (strategic thinking)
Knowing how to break it down (task decomposition)
Knowing how to evaluate quality (critical judgment)
Knowing how to communicate impact (visibility)

Coding was just the tool we used to execute on those skills. A really important tool, sure.

What’s happening now is that the tool is changing. The execution layer is being automated. But the thinking, the judgment, the strategy? That’s still ours.

If anything, AI is forcing the industry to acknowledge what good developers have always known: the hard part was never the syntax. It was figuring out what to build, why it matters, and whether it actually works.

The developers freaking out about “AI replacing us” are often the ones who built their identity entirely around code execution. And I get it, that was the most visible, most measurable part of the job. It’s what we practiced, what we got good at, what differentiated us.

But it was never the whole job. And now we’re being forced to reckon with that.

We’re the Canary in the Coal Mine

Software developers are experiencing this transformation first not because we’re special, but because we’re closest to the technology. We use AI to automate our own work. Of course it’s impacting us fastest.

But every profession is next.

The writer using AI to draft articles. The designer using AI to generate concepts. The analyst using AI to build models. The lawyer using AI to review contracts.

Everyone is about to face their own version of this identity crisis: “What is my job when AI can do the execution better than I can?”

We don’t have answers yet. We’re navigating in real-time, making it up as we go.

Navigating the Blur

I don’t have a clean conclusion here. No five-step framework for staying relevant. No confident prediction about where this goes.

What I do know:

The technology won’t slow down. We can’t wish our way back to a simpler time.

Skills still matter, but which ones is shifting. Deep technical knowledge isn’t obsolete, but it might not be sufficient anymore.

Intentionality is everything. We can drift into AI dependency without thinking, or we can engage with these tools critically, keeping what works, discarding what doesn’t, staying honest about trade-offs.

Trust isn’t binary. I’m somewhere on the spectrum between “review every line” and “ship without looking.” That’s probably where most of us are. And that’s okay, we’re all calibrating in real-time.

We’re figuring this out together. Nobody has it solved. The developers who seem most confident are probably just better at hiding their uncertainty.

The job is changing. Our identity as developers is changing with it. The only way through is acknowledging the discomfort and navigating it intentionally.

I still check the code. I still review the diffs. Maybe that makes me slow. Maybe that makes me careful. Maybe it’s just how I’m wired.

But I’m watching the people who don’t. And I’m taking notes.

We’re in uncharted territory.

And honestly? That’s both terrifying and kind of exciting.

What’s your experience with this shift? Are you in the “trust fully” camp, the “review everything” camp, or somewhere in between like me? I’d genuinely love to hear how other developers are navigating this.

The post The Developer Identity Crisis appeared first on sudoish.

Is AI Actually Making You Faster?

Mon, 09 Feb 2026 04:22:40 +0000

AI in software development is getting insanely powerful.

LLMs, copilots, agents, multi-step workflows…

…on paper, it all looks like massive productivity gains. And sometimes it is. But in practice, I’ve seen something very different happen over and over again: developers actually lose time, not gain it.

The main reason is simple:
AI can produce code that looks correct, works on the surface, and is confidently explained, but is subtly wrong.

And those subtle mistakes are often the most expensive ones.

The real problem: distance from the code

With modern AI tools, it’s very easy to become distant from the actual codebase.

Instead of designing, reasoning, and implementing, we:

write a big prompt
wait for a large chunk of code
skim it quickly
trust that “the AI probably knows better”

The code often runs. Tests might even pass. And the AI will confidently tell you the solution is solid and production-ready.
The amount of agents and MCPs added to the AI coding tool is so big nowadays that it is increasingly harder to discover where things could go wrong. And worse, developers tend to trust it more and more because it gives the sense that the ideal prompt, rules, and custom agents will be able to handle hallucination properly.

That’s where the danger is.

Because now you still have to read the whole implementation of a code a stranger has written, understand it, validate edge cases, debug weird behavior and repeat until things work as expected.

Except now you’re doing it while fighting authority bias — there’s an “expert” telling you everything is fine.

This is not faster. It’s verification debt.
It actually transforms developers into code reviewers of new cocky and condescending dev (the AI.

Here is one dummy example to illustrate this:

There is a feature in the backend that is used everywhere in the app. This function performs its action and then run some costly observability tasks.
These observability tasks should run in the background because the caller of the function doesn’t care about its response.
The correct approach is to schedule that extra processing asynchronously, fire and forget.

But the AI-generated code did something very subtle:
it awaited that processing instead of scheduling it as a background task.

In Python terms, think:

what should have been asyncio.create_task(...)
was instead written as await some_processing()

The result?

Everything still worked
No obvious errors
But every single call was now slower
Latency quietly increased across the system

This may be an easy bug to catch, but imagine how subtle bugs like this may pile up and get lost in the mix?

This happens because when developers rely too much on AI, they tend to read on the surface, not line by line. And with large outputs, that tendency gets even worse.

This hurts everyone, from juniors to seniors

For junior developers, this is especially dangerous.

If you rely too much on AI early on, you tend to skip the learning phase, you don’t build strong mental models and you accept solutions that you don’t fully understand.

But this isn’t just a junior problem.

For experienced developers, the risk is skill atrophy.
If you stop practicing fundamentals and let AI do most of the thinking you will most likely lose your instincts, code reviews get softer and your ability to spot subtle issues declines.

And then validating AI output becomes harder and harder, exactly when it matters most.

Ok, but what can we do now?

First rule: ask yourself if you even need AI here

One habit I find extremely important is this:

Before using AI, ask yourself:

“Is this actually faster with AI, or am I just outsourcing thinking?”

There are many cases where writing the code yourself is faster, clearer and safer, especially for core business logic, performance-critical paths, concurrency, security-sensitive code.

On the other hand, AI is excellent at things such as UI scaffolding, boilerplate, repetitive glue code, predictable transformations and, my favorite, reviewing my implementation helping me spot bugs.

Use it where it shines. Don’t force it everywhere.

Design first, then let AI fill the boring gaps

A strategy that works extremely well is this:

You design the structure. The AI fills in the details.

As an intermediate or senior developer, you usually already know what you want to build at a high level.

For example, a simple contact page:

frontend contact form
validation
backend API
database table
persistence logic

You don’t need the AI to decide what exists.
You already know that.

Instead:

define the structure yourself
break it into small, clear pieces
ask the AI to implement one piece at a time

This keeps context small, hallucinations lower, review manageable and you engaged with the code.

And it’s much faster than crafting one massive prompt and reviewing a massive output.

Small prompts, small context, small steps

Large prompts produce large hallucinations.

If you want better results:

reduce context
reduce scope
reduce responsibility per prompt

Instead of:

“Implement the entire feature end-to-end”

Try:

“Generate the frontend form UI”
“Add input validation for these fields”
“Implement this API handler with these constraints”
“Write tests for this specific behavior”

You stay in control, and the AI becomes a focused assistant — not an architect making assumptions for you.

Use TDD as a guardrail (not as dogma)

One very powerful pattern is combining AI with TDD-style thinking.

You don’t even need to be strict TDD.

Just:

define acceptance criteria
define what “correct” means
ask the AI to help write tests first (or alongside the code)

Tests force:

clarity
explicit behavior
less hand-wavy logic

They also give you confidence that the AI didn’t just produce something that looks right.

Automate the boring validation

Linters, formatters, type checkers, static analysis — all of these matter even more with AI-generated code.

Humans skim.
Tools don’t.

Let automation catch bad patterns, unsafe constructs, incorrect usage and inconsistent styles.

These are cheap guardrails that pay off immediately. Additionally, these can easily become default rules for the ai in your project or personal configuration.

Stay sharp: practice fundamentals on purpose

Here’s something I strongly believe:

The more AI advances, the more important fundamentals become.

If you’re not practicing DSA, system design, concurrency basics, you slowly lose the ability to judge whether a solution is good or not.

One simple habit I highly recommend:

one LeetCode problem a day

It doesn’t have to be intense.
Just enough to keep your brain in shape.

It makes you more engaged with code and more critical during reviews. It also helps you to be more capable of spotting subtle issues and better at validating AI output.

And yes, it also helps when reviewing code written by teammates who are also using AI.

AI is a power tool not autopilot

AI is incredible.
It can make you much more productive.

But only if you stay engaged, keep thinking, keep practicing and stay in the driver’s seat. The goal isn’t to fight AI. The goal is to use it deliberately, with good habits and strong guardrails.

Otherwise you’re not saving time, you’re just postponing the cost.

The post Is AI Actually Making You Faster? appeared first on sudoish.

Why Code Generation Needs Structure: How Programming Knowledge Graphs Are Changing the Game

Thu, 29 Jan 2026 23:35:45 +0000

Large Language Models (LLMs) have become indispensable tools for developers. They autocomplete functions, translate natural‑language instructions into code, and even solve algorithmic problems with surprising fluency. Yet, as anyone working with real‑world repositories knows, these models still stumble when the task requires deep contextual understanding. They hallucinate APIs, mis-handle variable scopes, and produce code that “looks right” but fails at runtime.

Why does this happen? Because most LLMs treat code as text—long sequences of tokens—rather than as structured, interdependent systems. And that’s where a new idea is gaining traction: Programming Knowledge Graphs (PKGs).

The Problem With Flat Retrieval

Traditional Retrieval-Augmented Generation (RAG) systems try to help LLMs by pulling in relevant snippets from a codebase. But these systems rely on flat retrieval: chunking files into fixed token windows and embedding them for similarity search. This works for natural language, but not for code. Cut a paragraph in half and you still have meaning; cut a function in half and you break it.

Flat retrieval often returns fragments that are semantically relevant but syntactically incomplete. The result? Models generate code that passes the “vibe check” but fails the compiler.

Enter Programming Knowledge Graphs

PKGs rethink retrieval from the ground up. Instead of treating code as text, they treat it as structure.

• Code is parsed into Abstract Syntax Trees (ASTs)
Functions, classes, and blocks become nodes in a graph.
• Documentation becomes JSON-based DAGs
Tutorials and guides are broken into structured, navigable fields.
• Retrieval happens at the level of functions or blocks, not arbitrary chunks.

This shift dramatically improves the quality of retrieved context. In benchmark tests like HumanEval and MBPP, PKG-based retrieval boosts pass@1 accuracy by up to 20–34% compared to dense or sparse retrieval alone.

The Hidden Trade-Off

But structure introduces a new challenge. When PKGs retrieve only the relevant block of code—say, a try/except clause—they often exclude the variable definitions or imports that block depends on. This leads to a spike in NameErrors and TypeErrors, even as logical correctness improves.

In other words: PKGs help models think better, but sometimes give them incomplete ingredients.

Toward Dynamic, Execution-Aware Retrieval

To address this, researchers are now exploring a more adaptive architecture: the Dynamic Execution-Aware Knowledge Graph (DE-KG).

This next-generation approach blends structural rigor with agentic reasoning:

• Dependency-aware nodes that carry variable definitions
• Hybrid sparse–dense–graph indexing for richer retrieval
• Execution-guided reranking, where candidate code is tested before selection
• Active graph traversal, allowing the system to “zoom out” when context is missing

The goal is simple but ambitious: retrieval that understands not just what code looks like, but how it behaves.

The Future of Code Generation

The shift from text-based to structure-aware retrieval marks a turning point in AI-assisted programming. PKGs show that respecting the shape of code—its syntax, hierarchy, and dependencies—can dramatically improve generation quality. But the next leap will come from systems that combine structure with dynamic reasoning and execution feedback.

In short, the future of code generation isn’t just bigger models. It’s smarter context.

Third-Party Logic - When You Run Code You've Never Seen

Tue, 20 Jan 2026 19:30:32 +0000

At some point on every plant floor, an uncomfortable truth gets quietly accepted:
"You are running code you've never seen, never reviewed, and don't fully control."
And in OT and ICS environments, that is a daily operational reality.

From OEM-supplied PLC blocks to vendor remote support tools, from safety logic libraries to AI-driven optimization modules, third-party logic is deeply embedded into modern industrial systems. It often arrives wrapped in trust, urgency, or contractual obligation. And once deployed, it tends to stay there for years, untouched, unquestioned, and largely invisible.
That's where the danger begins.

The Hidden Reality of Third-Party Logic

Unlike IT software, third-party logic in OT is rarely transparent. Vendors routinely deliver compiled function blocks, encrypted ladder logic, or "black box" firmware updates that operators are discouraged, or contractually prohibited, from inspecting. As a result, asset owners end up executing logic whose behavior they infer rather than understand.
Because of this, trust quietly replaces verification. The logic works, the process runs, and production targets are met, so nobody asks what else the code might be doing. However, operational success does not equal security assurance. In fact, in ICS environments, reliability often masks risk rather than eliminating it.

Why This Problem Is Unique to OT and ICS

In IT environments, running third-party code is expected, but it's surrounded by layers of visibility: source reviews, sandboxing, EDR, patch cycles, and rapid rollback. In OT, the situation is fundamentally different.

To begin with, availability outweighs inspection. Plant teams are trained to avoid touching working systems, which means third-party logic often remains frozen in time. Additionally, many controllers lack native logging or runtime visibility, making it difficult to observe what logic is actually doing during execution.

Furthermore, third-party logic often interacts directly with physical processes. This means a logic flaw is not only a cyber issue, it can translate into unsafe states, equipment damage, or environmental harm. In OT, software behavior has kinetic consequences.

How Third-Party Logic Becomes a Silent Attack Surface

Because third-party logic is trusted by default, it often bypasses traditional security scrutiny. Vendors are given broad access privileges, remote connectivity is left enabled, and logic updates are applied without independent validation.

As a result, several risks quietly accumulate.

First, malicious intent becomes hard to detect. A logic block that subtly alters thresholds, delays alarms, or suppresses fault conditions can blend seamlessly into normal operations. Second, unintentional vulnerabilities persist. Poorly written logic, hardcoded credentials, or insecure communication routines can sit unnoticed for years. And third, supply chain compromise becomes invisible. If a vendor's development environment is breached, compromised logic can enter your plant without triggering any alarms.

Each of these risks exists not because teams are careless, but because the environment was never designed for transparency.

The Contractual Trap of "Vendor Intellectual Property"

One of the most overlooked aspects of this issue is legal rather than technical. Many vendors classify control logic as intellectual property, restricting access to source code or even detailed documentation. This places asset owners in a paradoxical position: they are responsible for the safety and security of systems they are not allowed to fully inspect.

Consequently, cybersecurity governance stops at the vendor boundary. Risk assessments exclude logic internals. Incident response plans assume vendor availability. And security accountability becomes blurred between ownership and authorship.
In practice, this means you are accountable for outcomes, but dependent on third parties for understanding causes.

Cybersecurity threat in industrial control roomWhy Traditional Security Controls Don't Solve This
It's tempting to assume that firewalls, network segmentation, and access controls are enough. While they are essential, they do nothing to address the logic itself. Once third-party code is running inside a PLC, safety controller, or industrial application, perimeter controls are irrelevant.

Similarly, vulnerability scanning and patch management fall short. You can scan the device, but not the logic. You can patch the firmware, but not the hidden behavior embedded in function blocks. Without logic-level visibility, security remains superficial.

Therefore, the real risk is authorized execution of unverified behavior.

Building Visibility Without Breaking Operations

The solution is not to ban third-party logic; that's unrealistic. Modern industrial systems depend on vendor expertise and prebuilt functionality. Instead, the goal must be controlled trust.
This begins with architectural visibility. Asset inventories should include not just devices, but logic ownership: who wrote it, who maintains it, and when it was last reviewed. Change management must extend to logic updates, even when provided by vendors.

In addition, behavioral monitoring becomes critical. Instead of trying to read every line of code, organizations should focus on understanding expected behavior and detecting deviations at runtime. Process-aware anomaly detection, logic checksum validation, and configuration baselining provide practical ways to gain assurance without disrupting operations.

Equally important is contractual evolution. Security review rights, incident disclosure requirements, and update transparency must be embedded into vendor agreements. Trust should be formalized, not assumed.

The Mindset Shift OT Needs

Ultimately, the biggest change is cultural. OT teams must move from "it works, don't touch it" to "it works, but do we understand it?" Security teams, in turn, must respect operational constraints while pushing for deeper assurance.

Third-party logic is not inherently dangerous. What makes it risky is invisibility combined with permanence. When code runs for a decade without review, it becomes infrastructure, and infrastructure is hard to question.

Final Thought

Every PLC cycle executes instructions that shape physical reality. When those instructions come from sources you've never seen, you are operating on borrowed trust.

In modern OT and ICS environments, cybersecurity is no longer just about keeping attackers out. It's about knowing what you've already let in.

And the most dangerous code is not the one that crashes systems, it's the one that runs perfectly, silently, and unquestioned.

How to Verify a Smart Contract the Right Way (A Real, Practical Guide) Smart contract verification

Sat, 20 Dec 2025 22:52:41 +0000

How to Verify a Smart Contract the Right Way (A Real, Practical Guide)
Smart contract verification is not just a “nice to have” — it’s a core trust signal in crypto. Whether you’re building a DeFi project, a utility token, or experimenting with blockchain tech, verification shows transparency and professionalism.
Here’s a clear, real-world breakdown of how it’s actually done.

Deploy the Contract Correctly
Before verification, your contract must already be deployed on-chain (BSC, Ethereum, etc.).
Make sure:
The deployed bytecode matches your source code
You used a stable compiler version (don’t change it later)
Constructor parameters are saved
Mistakes here cause 90% of verification failures.
Use the Same Compiler & Settings
When verifying on BscScan / Etherscan:
Compiler version must match exactly
Optimization ON/OFF must be the same
If optimization is ON, use the same runs number
Even one small mismatch = verification fail.
Use Clean, Readable Code
Avoid:
Hidden logic
Obfuscated functions
Unnecessary permissions
A verified contract should be easy for anyone to read.
If users can’t understand it, they won’t trust it.
Verify on the Official Explorer
Use:
BscScan for BNB Smart Chain
Etherscan for Ethereum
Paste:
Contract address
Solidity code
Constructor arguments (if any)
Once verified, the contract becomes publicly readable and interactive.
Add Token Metadata (Optional but Important)
After verification:
Add token logo
Add social links
Add description
This improves visibility in wallets, explorers, and dApps.
Why Verification Matters
A verified contract:
Builds investor confidence
Reduces scam accusations
Allows wallet integrations
Enables analytics & listings
Shows you have nothing to hide
In crypto, transparency is value.
Final Thought
You don’t need hype to build trust.
You need clean code, verified contracts, and consistency.
Projects that focus on fundamentals always last longer.

Don’t Repeat Yourself (DRY) the Right Way: How to Reuse Code Without Creating a Mess

Tue, 25 Nov 2025 16:28:41 +0000

Every developer has heard “Don’t Repeat Yourself” (DRY)

How much code reuse is too much?
Am I over-abstracting?
Should this be a helper? A util? A service? A hook?

The truth:

Bad DRY creates more problems than it solves.
Good DRY makes your code predictable, clean, and future-proof.

DRY is not just removing duplication

it’s learning what deserves reuse and what deserves separation.

This post walks you through how to write reusable code the right way

Why DRY Matters

Good reuse helps you:

Fix bugs once instead of 5 times
Scale faster
Reduce cognitive load
Keep your project consistent
Avoid “copy-paste debt”

But bad reuse leads to:

Unnecessary abstractions
Confusing utilities
One giant file everyone is scared to touch
“Helper” folders full of black magic

Let’s fix that.

Step 1: DRY Only When the Behavior Repeats (Not the Code)

Most developers refactor too early.

Look at these two functions:

function createUser() {
  console.log("Creating user…");
  // some logic
}

function createProduct() {
  console.log("Creating product…");
  // some logic
}

These look similar.
But should they be merged?

❌ No.
The only repeated line is a console log the behavior is different.

DRY is not about removing repeated lines.

It’s about removing repeated logic.

Step 2: Start With “Local Reuse” Before “Global Reuse”

Most developers jump straight to a /utils folder.

Instead, follow this rules

If only one feature uses it, keep it inside that feature.
If two features use it, promote it to a shared place.

Example React structure:

/features
  /auth
    login.js
    useLogin.js
  /dashboard
    useDashboard.js
/shared
  /hooks
    useFetch.js   ← used by multiple features

You “graduate” code only when needed.

Step 3: Extract Reusable Code the SMART Way

Before extracting shared code, ask:

Will this logic change in different ways depending on the feature?

If yes → keep it local.
Does this logic repeat AND behave the same?

If yes → extract it.
Does extraction make the code clearer or more confusing?

If confusing → stop.

Step 4: Real Examples of Good Reuse

Example: Reusable API Client

Bad:

fetch("/api/users")
fetch("/api/products")
fetch("/api/orders")

Good:

export async function api(url, options = {}) {
  return fetch(url, options).then(res => res.json());
}

Step 5: The DRY Traps (Avoid These at All Costs)

Over-abstracting early

Don’t create files “just in case.”
Giant utility folders

If you have a helpers.js with 37 functions, it’s time to rethink.
Mixing unrelated logic

utils/index.js containing API logic, string formatting, date parsing, and a random debounce function.
Creating shared code for one-off logic

Not everything needs reuse.

Step 6: When to Refactor for Reuse

Refactor when:

Two modules copy-paste the same logic
Fixing a bug means changing multiple files
Code feels “the same but slightly different”
You keep writing similar boilerplate

If you catch yourself repeating work, that’s your signal.

Final Thought

DRY isn’t about having zero duplication, it’s about smart duplication and smarter reuse.

Good code is:

clear
predictable
discoverable
reusable when needed
duplicated when necessary

Yes, duplication is sometimes the right choice.

Your goal isn’t to write fancy code.
Your goal is to write code that future you, your teammates, and your project can trust.

Software Testing for Beginners

Thu, 16 Oct 2025 11:46:31 +0000

Software testing is an important phase in the Software Development Life Cycle (SDLC). It ensures that the software product is reliable, performs as expected, and meets user requirements. According to Robert Glass, the most important thing is user satisfaction.So, to make a compliant product as per the user requirements and needs, we need testing to ensure the quality of software is maintained and there are no defects in the software when it is made available to the end users.

Testing is usually performed in multiple levels, starting from small code units to the complete system, to catch errors as early as possible.

Major types of Testing

Even though there are many types of testing, we will focus on the major three listed below :

Unit Testing
Integration Testing
System Testing

Unit Testing

Unit Testing focuses on testing the smallest individual parts of the software usually functions, methods, or classes to ensure each component works correctly in isolation.The main goal is to verify that each unit performs as intended, independent of other parts of the system. It is done by the developers during the coding/development phase.
Example : Suppose you are developing a calculator app, testing whether the add() or divide() function returns the correct result would be considered Unit Testing.

Now the problem with testing an individual component is that it may be calling some other function or dependent on some other module. Now there is a high chance that other module is not ready yet. So to test our original module, we need some fake programs known as stubs and drivers.

Stub

A stub is a fake or temporary module used to simulate a called function that has not been developed yet.
It provides dummy data or simple output to help test the main unit.

To put it simply, Stub replaces the module that your code calls.

Driver

A driver is a temporary main program used to call and test a module that is not yet connected to the main system.
It sends input to the unit and checks the output.

To put it simply, Driver replaces the module that calls your code.

Real World Example (E-Commerce Platform)

Imagine you are developing an e-commerce website.
There are three modules:

LoginModule : handles user login.
CartModule : adds and removes items.
PaymentModule : processes payments.

Case 1: Using a Stub

You want to test the CartModule, but the PaymentModule isn’t ready yet.
The Cart module needs to “call” the Payment module to process payment.
You create a stub that pretends to be the Payment module and returns a fake success message.

// Stub for PaymentModule
string processPayment(int amount) {
    return "Payment Successful (Stub)";
}

So when you test the Cart module, it behaves as if the payment worked, even though the real payment system isn’t built.

Case 2: Using a Driver

Now suppose the LoginModule is not ready, but you want to test the CartModule (which normally gets called after login).
You create a driver that simulates a login and directly calls the Cart module.

// Driver for CartModule
int main() {
    cout<<"Driver: Simulating Login...\n";
    addToCart("Laptop", 2);  // Calling the Cart module
    return 0;
}

The driver acts like a test launcher to check if the Cart module works properly — without waiting for the login feature.

Tools Used

JUnit (Java)
NUnit (.NET)
PyTest (Python)
Google Test (C++)
Jest (JavaScript)

Benefits

Detects bugs early in the development.
Makes debugging easier.
Improves code reliability and maintainability.

Integration Testing

Integration Testing checks if different modules or components work together correctly after being combined. So we combine multiple modules either incrementally or all at once(not followed in real life).

Its goal is to verify the data flow between integrated modules and to identify any kinds of interface defects. Example : Continuing the calculator program, after testing the add() and subtract() functions individually, you perform integration testing to ensure they work together correctly when combined in a larger “calculator module” or with the user interface. It is done right after unit testing, and it is usually done by the testing group. (Sometimes, it involves the developers too).

Types of Integration Testing

Big Bang Approach : All modules are integrated together at once.
Incremental Approach : Modules are integrated and tested one by one:
- Top-Down (start from higher-level modules)
- Bottom-Up (start from lower-level modules)

Big Bang Approach

In the Big Bang approach, all modules are integrated at once and then tested as a complete system.

Pros:
- Easy to implement if all modules are ready.
- Simple process for small projects.
Cons:
- Hard to identify which module caused a failure.
- Debugging is difficult for large systems.
Example: On an e-commerce platform, the Cart, Payment, Login, and Product modules are all combined at the same time and tested together.

Incremental Approach

In the Incremental approach, modules are integrated and tested one by one.

Pros:
- Easier to identify errors.
- Bugs can be fixed immediately.
Cons:
- Takes more time than Big Bang.
- Requires planning the order of integration.

There are two main types of Incremental Integration:

a) Top-Down Integration

Start testing from the higher-level modules and move down to lower-level modules.
Example: Test the overall Checkout module first, then integrate and test the Cart module, then the Payment module, and so on.
Note: Sometimes stubs are needed to simulate lower-level modules that aren’t ready yet.

b) Bottom-Up Integration

Start testing from the lower-level modules and move up to higher-level modules.
Example: Test the Payment module first, then Cart module, then finally the Checkout module.
Note: Sometimes drivers are used to simulate higher-level modules that call the lower ones.

Tools Used

JUnit (for integration suites)
TestNG
Postman (for API integration)
Selenium

Benefits

Detects interface mismatches early.
Ensures smooth interaction between modules.

System Testing

System Testing evaluates the entire integrated system as a whole to verify that it meets the specified requirements.It ensures that all components and features function together properly in the target environment.
Example : In the calculator app, system testing would verify that the full app including input handling, UI, and calculations works correctly on the user’s device.

Tools Used

Selenium
LoadRunner
QTP (UFT)
JMeter

Benefits

Validates end-to-end system behavior.
Checks compatibility, usability, and performance.
Detects issues that only appear in the full system.

When and Why to Rewrite OOP Code in Functional Style

Sat, 05 Jul 2025 19:31:02 +0000

When and Why to Rewrite OOP Code in Functional Style

Rewriting a large object-oriented programming (OOP) codebase into a functional programming (FP) style is a bold and often controversial move in software engineering. While the challenges are significant—including a steep learning curve, possible disruptions to productivity, and the complexity of transitioning a live system—the rewards can be equally transformative. Under the right circumstances, refactoring OOP code into a functional paradigm can bring enhanced maintainability, scalability, and even performance gains to your system. In this article, we’ll explore when such a rewrite makes sense, the benefits it offers, and the key considerations you must account for.

This deep dive is intended for software architects, senior developers, and engineering managers who are contemplating or currently planning a paradigm shift in their software systems. We’ll detail the scenarios where this shift is not only justified but potentially game-changing.

Understanding the Philosophical Divide: OOP vs Functional Programming

Before diving into the "when" and "why," it's essential to understand what distinguishes these two paradigms. Object-Oriented Programming organizes code around objects—collections of data and behavior—relying heavily on inheritance, polymorphism, and encapsulation. It's widely used and deeply entrenched in enterprise-level applications, particularly in languages like Java, C++, and C#.

Functional Programming, on the other hand, emphasizes pure functions, immutability, and declarative code. Rather than modifying state, FP favors data transformations. Languages like Haskell, Elixir, and Clojure embody this approach, though functional styles can also be adopted in modern multi-paradigm languages such as Python, JavaScript, Kotlin, Scala, and even Java.

These two paradigms don’t just differ in syntax; they represent fundamentally different ways of thinking about problems and solutions. Shifting from OOP to FP is like switching from building blueprints to designing ecosystems—each approach has its strengths and limitations.

Scenario 1: Taming Complex State Management

One of the most compelling reasons to move from an object-oriented to a functional codebase is to reduce the complexity of state management. In large systems, tracking state mutations across deeply nested objects and shared mutable data can become nearly impossible, leading to elusive bugs and maintenance nightmares.

Functional programming enforces immutability and encourages the use of pure functions, which do not rely on or modify external state. This significantly simplifies reasoning about code. When each function has a clear input and output with no side effects, debugging and testing become much easier. Systems that previously required complex mocking and integration tests can now be validated with straightforward unit tests.

For systems where state changes are a constant source of bugs—such as real-time applications, distributed systems, or financial transaction platforms—a functional rewrite can lead to dramatic improvements in both reliability and maintainability.

Scenario 2: Scaling for Concurrency and Parallelism

Modern applications must often scale across multiple processors or even distributed clusters. Object-oriented codebases often struggle in this regard because shared mutable state introduces race conditions and makes concurrency error-prone. Even with synchronization mechanisms like locks or semaphores, the risk of deadlocks, resource contention, and performance bottlenecks remains high.

Functional programming offers a better fit for concurrent execution. Since functions avoid side effects and data is immutable, operations can be safely executed in parallel. Frameworks like Akka (for Scala) or Elixir’s OTP harness functional principles to achieve fault-tolerant concurrency at scale.

If your application must support thousands of simultaneous users, handle parallel data streams, or interact with asynchronous services, rewriting critical portions in a functional style can drastically improve performance and reliability.

Scenario 3: Reducing Technical Debt in Legacy Systems

Legacy codebases often evolve into monoliths riddled with tight coupling, hidden dependencies, and tangled inheritance hierarchies. As features are bolted on over years, the system becomes brittle and resistant to change—a state commonly referred to as technical debt.

Functional programming encourages modularity, composition, and stateless design, which naturally lead to codebases that are easier to maintain and extend. Functions can be reused without worrying about the side effects of hidden states. When dealing with a legacy OOP system that’s becoming too costly to maintain, a functional rewrite—even partial—can serve as a strategic investment that reduces long-term costs.

It’s worth noting that such rewrites can be done incrementally. Many languages support both paradigms, allowing for gradual adoption. For example, teams working in JavaScript can begin using functional libraries like Ramda or Lodash/fp before committing to a full architectural overhaul.

Scenario 4: Improving Testability and Reliability

Testing object-oriented systems often requires mocking complex objects, managing dependency injection, and simulating state changes—all of which can make writing tests a laborious process. This overhead frequently leads to insufficient test coverage and increased risk of bugs in production.

In contrast, functional code is naturally testable. Pure functions can be tested with simple input/output comparisons, and the absence of side effects means there’s no need for elaborate setup or teardown routines. As a result, teams can achieve higher test coverage with less effort.

Rewriting parts of an OOP system into a functional style can thus be a strategic move to increase confidence in the system’s correctness, reduce bugs, and streamline continuous integration processes.

Scenario 5: Preparing for Domain-Driven Design (DDD)

Domain-Driven Design seeks to model complex domains in a way that reflects real-world business logic. While traditionally associated with OOP, DDD principles—like bounded contexts, aggregate roots, and domain events—also map well to functional programming.

In fact, functional languages can provide better abstraction tools for modeling business logic due to their emphasis on algebraic data types, pattern matching, and immutability. These features make it easier to write clear, intention-revealing code that’s resistant to misuse and logically consistent.

Organizations looking to modernize their architecture by adopting DDD may find a functional approach not just compatible but actually advantageous.

Scenario 6: Enhancing Developer Productivity and Onboarding

While functional programming has a reputation for a steep learning curve, once developers become proficient, productivity often increases. Code tends to be shorter, more predictable, and less error-prone. Additionally, functional code encourages declarative thinking, which can reduce cognitive load.

In a large OOP codebase, new developers may struggle to understand the intricate class hierarchies and implicit behaviors. By contrast, a well-structured functional codebase offers smaller, composable units that are easier to grasp in isolation.

If your team is experiencing high turnover or scaling rapidly, a shift to a functional codebase could reduce onboarding time and improve code quality across the board.

Scenario 7: Enforcing a More Disciplined Codebase

In OOP, discipline is often left to the developer. It’s possible—and common—to misuse inheritance, allow state to leak, or create “god objects” that violate separation of concerns. Functional programming is more restrictive by nature, which can be a blessing in disguise.

By enforcing immutability, discouraging side effects, and promoting composition, a functional style nudges developers toward better practices. This built-in discipline reduces the room for error and makes it easier to enforce architectural standards across teams.

In large organizations where code quality and consistency are critical, this can lead to more maintainable and scalable systems over the long run.

Strategic Considerations Before Rewriting

Despite the benefits, rewriting an entire codebase is risky. It’s time-consuming, potentially disruptive, and can introduce regressions if not done carefully. Before committing, it’s crucial to conduct a cost-benefit analysis and determine whether the gains from functional programming justify the investment.

Often, a full rewrite isn’t necessary. Instead, consider refactoring specific modules—especially those with critical bugs, performance bottlenecks, or architectural issues—into a functional style. This hybrid approach allows teams to test the waters and gain experience before committing more fully.

It’s also essential to ensure that your development team has—or is willing to acquire—the necessary skills. Functional programming introduces concepts like higher-order functions, monads, and recursion that may be unfamiliar to developers with a purely OOP background. Investing in training and mentorship is key to a successful transition.

Tools and Languages That Support Functional Refactoring

Thankfully, many modern languages are multi-paradigm and support functional features natively. JavaScript, for example, has first-class functions and libraries like RxJS and Ramda. Kotlin offers powerful FP constructs like data classes, extension functions, and coroutines. Even Java has introduced functional features such as streams and lambdas in recent versions.

This means you don’t necessarily need to switch languages to adopt a functional approach. Instead, you can evolve your architecture gradually, leveraging functional principles where they make the most sense.

For teams starting from scratch, languages like Scala, Elixir, or F# may offer a more idiomatic experience. These languages are designed with FP in mind and provide robust ecosystems for building scalable, maintainable applications.

Real-World Success Stories

Companies like Twitter, Netflix, and Walmart have incorporated functional programming into their tech stacks to varying degrees. Twitter famously moved from Ruby on Rails to Scala to handle concurrency at scale. Netflix uses functional programming principles in its microservices architecture, leveraging RxJava and other reactive tools.

These case studies demonstrate that FP is not just academic theory—it’s being used in production to solve real-world problems at scale. For teams facing similar challenges, these examples offer both inspiration and proof of viability.

Final Thoughts

Rewriting a large object-oriented codebase in a functional style is not a decision to be taken lightly. It involves risk, effort, and a fundamental shift in how developers think about software. But under the right conditions—such as managing complex state, scaling for concurrency, or reducing technical debt—it can offer substantial rewards.

The key is to approach the transition strategically. Start small, focus on high-impact modules, invest in training, and adopt a hybrid model if needed. With careful planning and the right mindset, functional programming can become a powerful tool in your software engineering arsenal.

Coder Legion - Recent posts tagged code

How to Build an Interactive Web App Without Writing Code

Same Ingress, Different Defaults: What Changed When We Moved to HAProxy

HTTP to HTTPS Redirects

Connection Limits

Timeouts

Upstream HTTP Version

Basic Auth

X-Forwarded-For

HSTS Headers

Request Buffering

Where This Leaves You

Framer vs Webflow for Beginners: Which No-Code Builder is Best?

How to Make Your Website Cookie Compliant (GDPR and CCPA Tools)

Manage Your Infrastructure at Nine in Code

Your toolkit for interacting with us through code

The Nine API

nctl: The Nine Command Line Interface

Deploio

Terraform: classic Infrastructure as Code

Ansible: automating infrastructure setup

ArgoCD: Continuous Delivery the GitOps way

Explore, Contribute and Improve

Join the Conversation

The Unseen Intuition: Decentralization, Human Prompting, and the Art of Readable Code

Book Your Movie Tickets with Python

Features

What Is SARIF and How Does It Help Security Tools Work Together?

What is SARIF?

Why Was SARIF Created?

A Simple Example

How SARIF Helps Developers

One Format for Many Tools

Better Tool Interoperability

GitHub Code Scanning Support

Easier Aggregation

Conclusion

CodeMender IA — Universal Cloud Architect for VS Code

How I Review PRs with AI — Without Losing My Own Judgment

The Golden Rule: Context Isolation

The 4-Phase PR Review Workflow

Phase 1: Build Understanding (Human First)

Phase 2: AI First Pass (Filter the Noise)

Phase 3: The Deep Review (Pressure Testing)

Phase 4: The Verdict

The Author's Duty: Self-Review

Scaling the Process

Final Thoughts

cursor-claude-personas: Give Your AI Coding Assistant a Domain Expert Brain in 30 Seconds

cursor-claude-personas: Give Your AI Coding Assistant a Domain Expert Brain in 30 Seconds

The Problem: Generic AI Gives Generic Code

What Is cursor-claude-personas?

Supported tools

How to Use It — Step by Step

Step 1: Clone the repo

Step 2: Pick the persona that matches your current work

Step 3: Copy the persona into your project

Step 4: Reopen your editor or start a new session

Bonus: Enable the auto-skill router

All 38 Personas

What Makes This Different From a .cursorrules File?

Real-World Example

How the Folder Structure Works Under the Hood

Rules (rules/)

Skills (skills/)

Switching Personas Mid-Project

Contributing a New Persona

Where to Get It

Summary

I’ve been producing bad code (because of AI)

What You’ll Learn

How to use the DHT22 sensor with ESP8266?

Setup Requirements

Integrate Using Pre-built Libraries.

PlatformIO Setup

How to Code for DHT22 Sensor with ESP8266?

Compile and Connection of DHT22 with ESP8266

Uploading the code to ESP8266

Conclusion

Introduction to Go generics?

What Makes This Different From a `.cursorrules` File?

Rules (`rules/`)

Skills (`skills/`)