In my last post, I admitted how badly I underestimated building Wrench Wise — how “how hard can it be” became nine months and 400,000 lines of code. But I skipped the part where it first felt possible. Before the long slog, there was a moment of real magic. This is about that magic — and the very real limits hiding inside it.

Describe it to a prompt, and it appears

The tool that got me off the ground was a vibe-coding platform called Emergent. Back in 2025, the way it worked was almost absurd: you typed what you wanted into a command prompt, an AI built a web app from your description, and a working application appeared — running live on their servers.

My first working prototype of Wrench Wise — a very basic maintenance tracker, nothing fancy: track a vehicle, log its service, and not much more — came together in a day or two. Not a mockup. A real, running app I could open in a browser.

Here’s the part that still makes me smile, though: the app came together in a day or two, but the thinking took a week. I spent that week in long conversations with my son — who, unlike me, is a very talented programmer. He was deeply skeptical of the whole AI-coding idea, and (as you’ll see) for good reason. We talked through what I’d built, what it was missing, and whether this was a toy or the start of something real. That ratio turned out to be the whole project in miniature: the code was fast, the understanding was slow, and the understanding was the part that mattered.

What it did genuinely well

The skeptics get this wrong as often as the hype merchants do, so let me be fair: vibe-coding platforms are extraordinary at one specific job — proving an idea, fast.

• Zero setup. The biggest wall for a non-developer — the toolchain, the environment, the “I can’t even get it to run” problem — simply wasn’t there.
• Momentum. I had something real to react to in days. One working prototype teaches you more than a month of planning.
• It was live. No hosting puzzle, no DevOps. I could put it in front of people immediately.

If your only goal is to find out whether an idea is worth building at all, I’d point anyone here.

The corner

Then I tried to make it real, and the limits showed up fast — and they weren’t the kind you patch.

It could only build a web app — no Apple or Google app. That limitation decided the shape of the whole project: Wrench Wise was born in a browser, because a web app was the only thing Emergent could make. A real mobile app on the App Store and Google Play was a long way off — a story for later in this series.

The architecture was a mess. Emergent dumped essentially all of the code into two or three files that just kept growing in size. My son, the programmer, took one look and was genuinely concerned — not because it didn’t run, but because nothing about it was built to grow. And that wasn’t cosmetic. As those files got bigger, every new feature took more processing, more time, and more money — because the tool had to chew through the whole mess again each time. Toward the end, it crossed the line from expensive into broken: the files got so large that Emergent would simply die trying to process them — fail outright, unable to make the change at all. The tool that built the app in two days couldn’t, by the end, reliably change it. It was not scalable, in the most literal sense: the cost of change went up as the project got bigger, which is exactly backwards from how good software is supposed to work.

So the economics turned against me. Emergent charged real money, and I kept feeding it — $20 at a time — trying to fix bugs and coax out reasonable features. There was no single catastrophic bug; there were just many, and getting any feature exactly right was a slog. Over about two weeks I poured close to $300 into it this way, $20 at a time, watching the returns shrink with every update as the files — and the bills — grew.

And then I realized what I was actually paying for. The first clue was small: Emergent let you pick the underlying AI model. Then I started noticing other users talking about features that only existed in Claude. The picture snapped into focus. Emergent wasn’t magic, and it wasn’t really Emergent doing the work — it was a middleman. A friendly command-prompt wrapper around Claude and OpenAI, the same frontier models I could go rent directly. A good layer. But a layer, with a markup.

Walking away

So I left. I walked away from about $100 in unused credits, because at that point throwing more money at it was the worse decision. (They still email me, to this day, asking me to come back.)

The whole Emergent era lasted two or three weeks. And I don’t regret a dollar of it, because it gave me two things I couldn’t have gotten any other way: a real, running app to react to — and a conviction that’s only grown since.

My son was skeptical, and he was right to be. Back then, the AI wrote code like a talented high schooler — it worked, sort of, but it was nowhere near what a professional would ship. That’s not an insult; it’s a snapshot of a moment. And the point is the trajectory: high-school-level then, dramatically better not long after. That’s why I hold both halves of this at once — AI is going to fundamentally change how software gets built, and it still has a long way to go.Holding both is, I think, the only honest place to stand.

The one door

There was exactly one thing that made leaving possible, and I’m grateful for it: Emergent let you export your code to GitHub.

That sounds small. It wasn’t. It was the difference between a prototype I’d have to throw away and a codebase I could actually take ownership of. That single escape hatch is the entire next chapter of this story.

The lesson the engineer in me should’ve seen coming

There’s a principle in systems architecture I forgot to apply to my own project: an abstraction is a trade. It buys you speed by taking away control — and sometimes by quietly bending the cost curve against you. That’s a brilliant trade when you’re proving an idea, and a terrible one when you’re trying to run something for years.

Prototyping tools and production tools are different jobs. Emergent got me to “it works” faster than I’d have believed. It was never going to get me to “you own this, you understand it, and you can run it for the next decade.” The mistake isn’t using the prototype tool — it’s confusing it for the production one, and pouring money into a platform you’ll eventually have to escape anyway.

Next up: the very first commit in my real git history — "Clean repo without large backup files" — what the export actually looked like (spoiler: a mess), and what it felt like to finally own my code. 

The post Vibe Coding Got Me to a Working App in Days — and a Corner I Couldn’t Get Out Of appeared first on McGlyn Consulting.

In my last post, I told you why I started building Wrench Wise: a driveway and a barn full of vehicles — a Class A motorhome, an F350, a tractor, a sailboat, three horse trailers — and not one app that understood a fleet like that. So I decided to build it myself.

And honestly? My first thought was: how hard can it be?

It’s a vehicle maintenance app. It tracks oil changes and dates. I’m a licensed engineer with 25 years in cybersecurity. I’ve got AI to write the code now. A month, tops.

It was not a month. Let me tell you how wrong I was.

On paper, I had no business being nervous.

I’m a licensed Professional Engineer. I spent 25 years in cybersecurity, much of it leading security architecture and running security organizations. And I’ve been hands-on with serious systems. I worked with other engineers on two different systems that ran the DNS for 750,000 residential and 37,000 business customers — the kind of infrastructure where an outage makes the news. I worked on a system to help protect the U.S. government from cyberattack. These weren’t toy projects.

So a little app to track when my truck needs an oil change? With AI doing the typing? Please. I’d defended the federal government from cyberattacks. This was going to be a relaxing retirement hobby.

That confidence lasted right up until I started building.

The part my confidence conveniently skipped.

Here’s the honest version, and it’s the one that matters. My craft is systems engineering and security architecture — not production software. On every one of those serious systems, I worked alongside developers whose coding skills were stronger than mine. I wrote code too — I wasn’t a bystander. But I could not have made any of it actually work without them. My job was the engineering, the architecture, and later the leadership: understanding the system, making the calls, seeing how the pieces fit and how they’d fail. The hard, production-grade coding leaned on people who were genuinely great at it.

That’s not a confession — it’s how good engineering organizations work. Specialists do what they’re best at. My value was never in out-typing the developers next to me; it was in knowing what to build, why, and where it would break. I’d just never had to carry production software across the finish line alone, because I always had people who could do that part far better than I could.

“Just oil changes and dates,” I said.

Then I actually sat down to model the thing.

Turns out “just oil changes and dates” is a fleet of vehicles measured in three completely different ways — miles, engine hours, and calendar seasons. An RV isn’t a vehicle; it’s three machines wearing a trenchcoat, each on its own schedule: the chassis and engine on mileage, the generator on hours, the house systems on the calendar. A tractor doesn’t care about your odometer — it counts hours. A horse trailer mostly needs its bearings watched and its tires replaced because rubber ages out whether you drive on it or not.

Every “simple” assumption I started with had a dozen exceptions hiding behind it. The data model alone — how do you even represent a thing that’s one asset to the owner but three maintenance schedules to the machine? — took longer than I’d budgeted for the entire app.

The wrenching was never the hard part. I can rebuild an engine. It was the thinking — and it turned out there was a mountain of it.

And the AI? The AI did not make it easy.

This is the part everyone gets wrong, so let me be precise.

AI didn’t turn me into a software engineer overnight, and it absolutely did not do all the work. An AI is a fast, capable, tireless collaborator that will also, now and then, confidently walk you straight off a cliff — write code that looks perfect and is quietly, dangerously wrong. Catching that became one of my real jobs.

What AI did do was give me back the thing I’d always relied on: a strong coding partner to turn the engineering into working software, while I did the engineering and made the calls. For the first time, I could attempt a project that previously would have required hiring a team I didn’t have. But “a partner who writes code fast” is a very different thing from “it builds the app for you.” The first is true. The second is the fantasy that sinks people.

What I was actually bringing to the table.

Here’s the realization that reshaped how I think about all of this.

For my whole career, I’d supplied the judgment, the architecture, and increasingly the understanding of what we were even trying to accomplish — while leaning on stronger coders to turn it into working software. With AI writing alongside me now, that division of labor didn’t disappear; it got sharper. When code can be generated on demand, writing it stops being the scarce, valuable thing. Understanding the problem becomes the scarce, valuable thing.

And on this problem, I wasn’t the junior partner anymore. Think about who’s actually equipped to build a maintenance app for people like me. Not necessarily the best programmer in the room. The person who’s done their own vehicle maintenance for forty years. The person who owns the motorhome that’s secretly three vehicles, the tractor measured in engine hours, the horse trailer whose bearings and floor you watch even though you barely drive it. The person who tried every existing app and knew exactly what they all got wrong.

That person was me. The AI could write the functions. It could not want what I wanted, and it could not know what a fleet owner actually needs at 7am in a cold barn. That knowledge — the domain, the judgment, the lived frustration — was the part I’d been building my whole career, and it turned out to be the part that mattered most. It’s also, as I’ll get into later in this series, the line between building a real app and generating a pile of impressive-looking junk.

So, how hard was it?

“How hard can it be” turned into nine months, nearly 4,000 commits, more than 400,000 lines of production code, and almost 12,000 automated tests — for the app I genuinely thought would take a month.

I don’t regret a minute of it. But I’d be lying if I said I saw it coming. The forty years of turning my own wrenches was worth more than any line of code I could write — and the gap between “how hard can it be” and what it actually took is most of what this series is about.

Next up: the very first tool I used to turn an idea into a working app in days — and the corner I painted myself into.

The post How Hard Can It Be? What a “Simple” Maintenance App Taught Me About AI-Assisted Engineering appeared first on McGlyn Consulting.

I couldn’t afford another car. So I did the only thing I could afford: I bought a Haynes repair manual, taught myself how the engine came apart, and rebuilt it. It ran. I drove it to school.

I’ve done most of the maintenance on my own vehicles ever since. That one breakdown turned into a forty-year habit.

The problem wasn’t the wrenching. It was the tracking.

Fast-forward to today. I’m semi-retired, doing some part-time consulting through McGlyn Consulting after 25+ years in cybersecurity — I retired from Deloitte as the Global Leader for Cybersecurity Architecture, covering all ~425,000 of the firm’s people. Before that I ran security at CableLabs and was CISO at Qwest/CenturyLink. And long before any of that, I started my career as a petroleum engineer at Mobil Oil — I’ve been a licensed Professional Engineer in Colorado since 1992.

So I’m comfortable with complex systems. But nothing prepared me for the logistics of maintaining a small fleet.

It started when we bought a Class A motorhome from my son. If you’ve never owned one: an RV isn’t a vehicle, it’s three vehicles wearing a trenchcoat. There’s the chassis and engine. There’s the generator, on its own hour-based schedule. There’s the house — water systems, slide-outs, seals, batteries. Everything is on a different calendar, and missing something doesn’t mean an inconvenience, it means a four-figure repair.

Then I looked at everything else in the driveway and the barn:

• A Ford F350
• A Ford Ranger
• A Ford Expedition
• A John Deere compact tractor
• A John Deere riding mower
• A sailboat — and its trailer
• And three horse trailers

Every one of those has maintenance needs. Oil, filters, fluids, bearings, brakes, seasonal layup, tires that age out whether you drive on them or not. I was the guy who could rebuild an engine, and I was still losing track of what needed servicing and when.

I tried the apps. None of them fit.

I did what everyone does first — I went looking for software. There are vehicle-maintenance apps out there, and I tried them. They were built for someone with one or two cars and a simple oil-change cadence. None of them understood a fleet. None of them understood an RV’s split personality, or a tractor measured in engine hours, or a horse trailer that mostly needs its bearings and floor watched.

None of them did what I actually wanted.

So I decided to build it myself.

That’s a sentence that’s easy to write and terrifying to act on. Because here’s the part I haven’t mentioned: I’m not a software developer.

Over the years I’ve touched a lot of languages — C, C++, Java, Perl, a little Python, some Fortran, Oracle databases. Enough to be dangerous. But I’ll say it plainly: I was never a good programmer. I’m an engineer and a security leader, not a software engineer.

What I am is stubborn, and curious. The same instinct that made me buy a Haynes manual instead of giving up on that smoking car made me wonder: could AI help me build the thing I couldn’t find?

That question turned into Wrench Wise — and into a nine-month, nearly-4,000-commit education in what it actually takes to ship real software when you’re not a real software developer.

That’s the story I’m going to tell in this series: the false starts, the funny disasters, the tools, the lessons, and the surprisingly hard parts (naming it was harder than I expected, and don’t get me started on advertising). Some of it is educational. A lot of it is just entertaining in hindsight.

Next up: how a guy who “was never a really good programmer” started building a real app — and the first tool that made it feel possible.

Stick around.

The post Why I Built Wrench Wise: From a Haynes Manual to an App Store appeared first on McGlyn Consulting.

Current Status and Timeline

The CRA is on a clear path toward implementation, with several key milestones already achieved:

• September 2024: Approval by the European Parliament
• December 2024: CRA entered into force
• September 2026: Manufacturers’ obligations for reporting exploited vulnerabilities and incidents commence
• December 2027: Main provisions will apply

These dates are crucial for executives to keep in mind as they strategize for compliance.

Key Requirements and Business Impact

The CRA establishes a tiered approach to product security, categorizing products into three classes based on their risk profile:

1. Critical Products:
   • Requires rigorous conformity assessments
   • Must obtain European cybersecurity certification
   • Examples: Industrial automation control systems, network management systems
2. Important Class II Products:
   • Requires third-party conformity assessments
   • Includes operating systems and smart meters
3. Important Class I Products:
   • May utilize harmonized standards or undergo third-party assessment
   • Examples: Network routers, identity management software

Core Obligations

Organizations must adhere to several core obligations under the CRA, including:

• Security by Design: Implementing security measures from the product design phase
• Security Updates: Providing updates for a minimum of five years or the product’s lifetime
• Vulnerability Reporting: Actively reporting exploited vulnerabilities within 24 hours
• Documentation: Maintaining comprehensive technical documentation for all products

These requirements signify a commitment to enhanced cybersecurity and consumer trust.

Industry Implementation Examples

Across various sectors, companies are taking proactive steps to comply with the CRA:

• Manufacturing Sector: Major manufacturers are integrating security requirements into their product design phases and establishing automated vulnerability scanning across supply chains
• Healthcare Technology: Medical device manufacturers are developing secure update mechanisms for connected devices and enhancing incident response procedures to comply with new CRA standards

Such initiatives not only meet regulatory demands but also enhance overall product security.

Relationship with Other EU Regulations

The CRA aligns with other significant EU regulations, creating a comprehensive cybersecurity framework:

• NIS2 Directive: Focuses on critical infrastructure cybersecurity, complementing CRA by addressing organizational security. Implementation deadline: October 18, 2024
• DORA (Digital Operational Resilience Act): Targets financial institutions and overlaps with CRA on digital resilience requirements. Applicable from January 17, 2025
• GDPR (General Data Protection Regulation): Pertains to personal data protection and requires coordination between security and privacy measures, already in effect since May 2018
• CSA (Cybersecurity Act): Provides a certification framework supporting CRA compliance and establishes standards for cybersecurity assessment

Preparation Guide for U.S. Companies

For U.S. companies conducting business in the EU, proactive preparation is essential. Here’s a structured timeline to guide compliance efforts:

Immediate Actions (Q2-Q3 2025)

• Assessment Phase:
  • Conduct a product portfolio review to identify CRA applicability
  • Evaluate current security practices against new requirements
• Documentation Preparation:
  • Begin compiling technical documentation
  • Establish systems for tracking vulnerabilities and incidents

Mid-term Actions (Q4 2025 – Q1 2026)

• Process Implementation:
  • Develop secure update mechanisms for products
  • Implement robust vulnerability management systems
• Organizational Alignment:
  • Train relevant personnel on CRA requirements
  • Update product development lifecycle to incorporate security measures

Long-term Actions (Q2 2026 – 2027)

• Certification and Testing:
  • Conduct third-party assessments where required
  • Obtain necessary cybersecurity certifications
• Continuous Improvement:
  • Monitor regulatory updates and refine processes accordingly
  • Adjust strategies based on early implementation feedback

Financial ImplicationsExecutives should be aware of the financial repercussions of non-compliance, which can include:

Executives should be aware of the financial repercussions of non-compliance, which can include:

• Fines up to €15 million or 2.5% of global annual turnover for security requirement violations
• Fines up to €10 million or 2% of global annual turnover for other obligations under the CRA

Conclusion

The EU CRA represents a significant evolution in product security requirements that will impact businesses worldwide. By understanding the CRA’s implications and preparing proactively, U.S. executives can ensure compliance while enhancing their organization’s cybersecurity posture.

As the digital landscape continues to evolve, aligning with regulations like the CRA, NIS2, DORA, GDPR, and CSA will not only mitigate risks but also foster consumer trust and confidence in their brand.

Note: This blog reflects the current status of the EU CRA as of April 2025. Organizations should consult with legal and cybersecurity experts for specific guidance on their compliance obligations.

References

European Commission – Cyber Resilience Act Official Page

• Provides official status, implementation timeline, and detailed guidance

Official Journal of the European Union

• Publishes authoritative, final legislative texts once approved
• Regulation (EU) 2024/2847

European Union Agency for Cybersecurity (ENISA)

• Cyber Resilience Act Requirements Standards Mapping

The post The EU Cyber Resilience Act: What Business Executives Need to Know in 2025  appeared first on McGlyn Consulting.

What is Security by Design?

Security by Design means integrating security from the ground up. Instead of reacting to vulnerabilities after systems go live, this approach ensures security is baked into the architecture, development, and deployment of all projects and platforms. It’s a mindset shift that treats security as a foundational component, not an afterthought.

This proactive strategy is essential for protecting sensitive data, critical infrastructure, and enterprise assets while enabling compliance with growing regulatory requirements.

1. Translating Policies into Actionable Technical Requirements

Most organizations have a wide array of security policies and standards. Unfortunately, these documents are often overlooked or misunderstood by technical teams.

To bridge this gap, cybersecurity teams should:

• Translate high-level policies into project-specific technical requirements
• Use filtering mechanisms like security questionnaires to tailor the requirements based on:
  • Type of project
  • Data sensitivity
  • Hosting model (Data Center, IaaS, PaaS, SaaS)
  • Technology stack (e.g., databases, frameworks)

Streamlining thousands of policies into 30-50 relevant technical controls improves adoption and reduces developer friction. Automation and integration into agile workflows increase the likelihood of proper implementation.

2. Building a Security Champions Program

Annual training alone isn’t enough. Elevate your security culture by identifying and training Security Champions:

• Developers, sysadmins, and engineers who receive deeper training
• Act as liaisons between cybersecurity and delivery teams
• Provide feedback to improve security processes

This grassroots approach increases awareness, strengthens business alignment, and ensures security considerations are embedded in day-to-day operations.

3. Conducting Threat Modeling Early

Threat modeling during the architecture phase identifies risks when it’s cheapest to fix them. Early detection can reduce vulnerabilities found in later testing phases by up to 50%.

To be effective:

• Integrate threat modeling into design tools already used by teams
• Leverage reusable components and secure design patterns
• Use tooling to suggest architecture improvements and visualize risks

This approach empowers developers and architects to build more secure systems from the outset.

4. Device and System Hardening

Harden configurations across devices, OS, and applications to reduce your attack surface. Use benchmarks from:

Limiting access to systems through firewalls and other mechanisms is a good defense in depth strategy to limit exposure of vulnerabilities.  Remember, risk is the combination of vulnerability and exposure to a threat actor who can exploit it.  If a vulnerability is not accessible, you are protected.

• Center for Internet Security (CIS)
• NSA and UK NCSC

Establish golden configurations that are applied from project initiation, not retrofitted at the end. Pair this with firewalls and access control to limit exposure. Remember: If a vulnerability isn’t reachable, it can’t be exploited.

5. Continuous Monitoring and Drift Detection

Security isn’t “set and forget.”

• Monitor for operational drift from your baseline configurations
• Use automation to audit and validate controls
• Avoid over-reliance on self-reporting

Many vulnerabilities arise from emergency changes that aren’t rolled back. Automated drift detection ensures controls remain effective.

6. Securing the Development Pipeline

Your software supply chain is just as important as the final product:

• Monitor for leaked credentials, secrets, or code tampering
• Secure CI/CD systems and version control
• Apply the same hardening principles to development infrastructure

A compromised pipeline can inject malicious code directly into your products, bypassing all other defenses.

7. Leveraging Threat Intelligence

Stay ahead of attackers by adapting your defenses based on emerging threats:

• Regularly review threat intelligence feeds
• Update your security policies, controls, and designs based on current TTPs (tactics, techniques, procedures)

A modern defense strategy is dynamic, not static.

8. Collaborating with Privacy and Compliance Teams

Security and privacy are deeply intertwined:

• Engage privacy teams early in the project lifecycle
• Combine security and privacy questionnaires to streamline compliance
• Balance the need for control with the need for privacy

Remember: You can have security without privacy, but you can’t have privacy without security.

9. Partnering with the Business

Security must align with business goals:

• Establish strong relationships through Business Information Security Officers (BISOs)
• Embed security champions into delivery teams
• Focus on “security at the speed of business”

Sometimes, risk acceptance is necessary to meet business goals. The key is ensuring that any deferred security remediation is prioritized once the product is live.

One real-world example: A VoIP product was shipped quickly with minimal controls, but the business deprioritized fixes — until the COO’s phone was hacked. Don’t wait for a crisis to act.

Final Thoughts: Make Security by Design Your Default

Security by Design isn’t a project. It’s a mindset and a long-term commitment.

By embedding security into every phase of your operations and aligning it with business goals, you can reduce risk, improve efficiency, and protect your brand in a fast-moving digital landscape.

Prevention is always cheaper than remediation. Make Security by Design your foundation, not your fallback.

The post Embracing Security by Design: A Practical Guide to Strengthening Cybersecurity in a Challenging Economy appeared first on McGlyn Consulting.