Jared Markell

What if coding agents could reliably implement your software? Not just for a single session... but for an entire project 🤩 I kept hitting the same wall: the agent would start strong, then drift, then hallucinate requirements I never mentioned. By session three, we'd lost the orientation completely. The problem wasn't the AI. It was me. I was "vibe coding"—prompting on instinct without structured constraints. So I explored a different approach: Spec-Driven Development. The idea: make specifications—not code—the primary artifact. You define what and why before the agent writes a single line of code. The specs become a "memory bank" of your intent. The agent references the memory bank and implements your intent. I tested three open-source frameworks (Spec-Kit, OpenSpec, AgentOS) to explore how Spec-Driven Development works. My takeaway? The specific tool matters less than the approach. Full breakdown of my learnings and experiences on my blog: https://lnkd.in/ek93HPnn #AICoding #AgenticAI #SoftwareEngineering #ClaudeCode #SpecDrivenDevelopment

27

22 Comments

When I deliver a project, I follow a 48-hour decision rule with my team. Every decision has an owner, options, and a deadline. If it doesn’t change the architecture or budget, it’s decided quickly. Forbes Technology Council recently featured this approach to reducing decision latency.

28

9 Comments

It’s easy to say “shared services.” It’s harder to build something your teams actually want to use. Platform thinking isn’t just APIs and tooling - it’s about reducing friction in a way that builds confidence at every layer. You know your platform is working when teams: ✅ Stop reinventing basic infrastructure ✅ Trust the defaults ✅ Ship faster because of the system, not in spite of it Platforms aren’t just technical - they’re cultural.

11

Chunking and snippet extraction has been a huge focus lately - my latest blog dives into some of the work we've done on this to date, including support for a chunk rescorer in our semantic reranking retriever, as well as some useful ES|QL primitives to get more visibility into chunks and snippets. #elasticsearch #semanticreranking #snippets #chunks #chunking #esql https://lnkd.in/e6UD7iii

13

If your team needs a Zoom call to deploy to Production, your architecture is broken. I see companies calling these "Release Parties." They aren't parties. They are "Collective Anxiety" sessions disguised as collaboration. I’ve sat on calls with 12 expensive engineers watching a Jenkins progress bar for 90 minutes. - The Backend Lead is there "just in case". - The QA Lead is there to give the "Go/No-Go". - The CTO is there because they are terrified. This isn't "DevOps". This is Theater. If you rely on human heroism to get code into production, you don't have a pipeline. You have a checklist of manual failures waiting to happen. The Rulebook: Make Deployments Boring Again. My goal is to make a deployment the most boring part of the day. If it’s "Exciting", we failed. Here is how I dismantle the "Release Party": 1. Automate the "Yes" (Kill the CAB): Stop holding "Change Approval" meetings. They are bottlenecks, not safety nets. We use Policy-as-Code (OPA/Kyverno). If the PR passes security scans, unit tests and meets the linting standards, the system approves it automatically. We codify the governance so we don't need a human to "bless" the release. 2. Progressive Delivery (Canary): Never deploy to 100% of users at once. Release to 5%, monitor the error rate (automatically), and promote or kill. No human decision required. 3. Feature Flags > Branching: We decouple "Deployment" (code on server) from "Release" (user sees feature). Ship the code dark. Turn it on when you’re ready. This kills the need for "Big Bang" releases. The Conclusion: A Lead Engineer’s job is to automate the fear out of the process. We should be celebrating Business Wins, not the fact that the server didn't crash during a deploy. The Question: Be honest: Is deploying code at your company a "Non-Event" or a "Heart Attack"? 👇 #DevOps #ContinuousDelivery #SRE #PlatformEngineering #RemoteWork #Leadership

171

11 Comments

Structured Events in Rails! OMG! I've been waiting for this for ~4 years. Want to send *proper* structured events? Yeah. Me too. This is the most exciting development in observability for Rails in... ...well, forever. This opens the door to proper OpenTelemetry instrumented Rails apps... ...with a single subscriber and an intuitive interface. But it's way more than that - it allows us to instrument *business* events. Things like: * Order Processed * Customer Paid * Invoice Created I'm beyond excited about the direction the Rails team has gone in. * Decoupled the subscriber from the instrumenter * Aligned the API with the ridiculously good error reporting * Namespaces for events This will open the door to massive improvements in the observability of Rails apps. A HUGE thanks to Adrianna Chang for leading this effort and getting a huge feature into Rails that's critical for modern observability. Kudos! Comment below with your questions about how to use observability and I'll answer what I can.

11

6 Comments

Remember that not only does shipping matter, but cleaning house. Clunky codebases with outdated code or core ideas are slow to develop in and require more bodies to just get stuff done. When you don't invest in core architecture that EVERYONE owns (Individual Codebases, Systems, Product, Management, Leadership), you break the trust and introduce delay. Yeah - solving problems means EVERYONE. I don't care what level you are or position you hold. TLDR: Core Architecture matters, but make it part of your CI/CD.

27

2 Comments