Trey Springer - Above Lending | LinkedIn

Last week I shipped a feature to production in a multi-million-line enterprise codebase. I'm not on the engineering team. (I am just the COO worrying about what is in the checking account and G5's partner/customer relationship). It took me about 30 minutes. The feature was trivial: a trash icon on the Home page so you can delete a workspace from the Recent Workspaces list. The kind of thing that sits in a backlog for months because it's never important enough to pull an engineer off real work. If you're a product manager or business owner living with complex enterprise software, you know this backlog. Dozens of small, obvious improvements. All waiting behind the same engineering queue. Here's what I actually did: 1/ I took the item off the backlog, pasted a screenshot into the G5 chat, and typed one sentence: "In the Home page, implement a deletion logic for the workspace via a trash icon." 2/ The Ontology went first. Before any code was written, G5 amended the architecture spec and the test contract to define the new control. 3/ Critically, it required reuse of the existing removal predicate, confirmation dialog, and deletion mutation already wired to the workspace switcher. No second implementation. Just a new entry point. (Claude Code - take that!) 4/ The Ontology review also flagged that this needed an end-to-end Playwright test, not just unit coverage. So it got one. Net code change: 26 lines. Plus tests. Then CI/CD ran for a few hours, the PR was reviewed, and it merged. My 30 minutes were the easy part. What made me comfortable pushing this into a codebase with sophisticated CI/CD and a lot of surface area for mistakes was not the speed. It was the guardrails. The Ontology knew the deletion path already existed, knew what it had to reuse, and knew what evidence it needed before the change could be called done. I didn't have to know any of that. This was the first time I felt what modern AI coding harnesses look like when they're inside a complex enterprise software lifecycle. Not a side project. Not Sunday-morning vibe coding. Not a mocked UI. Not "AI wrote some code." A backlog item became a spec, a test contract, a change, and a verified merge. And a non-engineer drove it, to a bar G5's software architects would approve, without engineers spending hours cleaning up after the exec's vibe coding session :-)

Eshan Chordia

Impulse AI • 2K followers

I’ve been using Claude Code on the side for the last week. I haven't coded in 10 years, but it’s making me feel like a builder again. A few observations on how I’m using it: The Workflow 📓 I give it a detailed PRD—problems, requirements, and specific details on how I want the solution to work. It handles the planning, I make a few tweaks, and then I just let it write the code on auto-approve. When it’s "done," I tell it to be its own worst critic. I ask it to analyze itself for mistakes, find bugs, and think like a hacker and a QA engineer. That loop actually got me to over 80% test coverage. The PM Perspective 💪 Honestly, I don't care if the code is "clean" or human-readable right now. As a PM, I care about the outcome. It hasn't hit production yet, so I know things like latency and technical debt will eventually matter, but for now, it doesn't bother me. I can give it a high-level problem—like lowering LLM costs—and it figures it out. If I hit a bug, it just thinks through different iterations until the bug is gone. It even walked me through a secure GCP setup and automated the deployment when I told it I was non-technical. The Takeaway 💡 If you have good taste and understand exactly what you want to build, the lack of engineering skills isn't a blocker anymore. It gives me a lot of confidence that I could build an entire product by conversing with Claude Code. I’m going to try out Claude team agents next to see how they work together. I'll share more once I have a few sessions under my belt.

Luis Martín Espino Rivera

EPAM NEORIS • 562 followers

Turnkey Doesn't Mean Hands-Off Every failed turnkey project I've seen died the same way: somebody read "turnkey" and heard "not my problem anymore." Eight months later a vendor hands over a zip file, a login, and a smile — and you discover the framework version is unsupported, the database has no indexing strategy, and the only person who understood the deployment just rolled off. Four things separate the projects that survive handover from the ones that don't: You own the rails. The vendor drives the train. Publish the approved stack before a single story gets estimated — front end (Angular / React / Vue), back end (.NET C# / Java / Python), cloud (Azure / AWS / GCP) — including minimum supported versions. Keep QA, Pre-Prod, and Production yours. A vendor who controls your deployment path controls your exit. Write the numbers down or you'll argue about them later. "Fast" isn't a requirement. "Under 200ms, 10,000 concurrent users, 99.9% uptime, OWASP compliance" is. If it isn't in the SOW, it's a favor — and favors evaporate under schedule pressure. Traceability is the cheapest insurance you'll ever buy. Work item (Jira / Asana / Azure Boards) → code → test case. That chain is what lets you answer "why does this exist?" two years after everyone involved has left. Define "done" before you need it. Production-ready software, architecture and API docs, test evidence, a warranty period with SLAs, and real knowledge transfer. KT is not a recorded call nobody watches — it's your engineers doing the work while the vendor watches. Turnkey shifts execution, never accountability. Do this well and you own a system. Skip it and you've rented one at purchase price. https://lnkd.in/e7ZBh2a9