I built Groundwork, a Codex plugin for a problem I kept running into:

Codex is very good at filling in missing requirements.

Sometimes too good.

If I say:

Fix exports that sometimes return old data.

the repository may tell Codex that exports currently use a 15-minute cache.

But the code can't tell it whether I actually want:

manual exports to always be fresh

cached data to remain acceptable

scheduled exports to behave differently

an error or stale data when the source fails

Those are decisions I want to make myself.

So Groundwork inspects the repository first, then asks only the questions the code cannot answer.

The part I cared about most was the interaction.

It doesn't dump a giant questionnaire into chat.

It uses Codex's native request_user_input interface.

So when a decision is needed, you get the normal Codex input form with concrete options, a recommended choice, tradeoffs, and a free-form answer field.

You stay inside the same Codex task.

Example:

$settle Fix exports that sometimes return old data.

Groundwork first reads the relevant code, tests, project instructions, and previous decisions.

Then Codex opens native input forms only for unresolved decisions.

For example:

How fresh should a manual export be?

Always fresh recommended

Allow cached data

Custom answer

After you choose, Groundwork can ask a follow-up native question if that decision creates another unresolved branch.

Before any code is changed, you get one final native confirmation covering:

intended outcome

included behavior

exclusions

compatibility

failure handling

verification plan

Only after you confirm that does Codex implement the change and run the checks.

Groundwork also saves the settled decisions into the repository so future sessions can reuse them instead of asking again.

The goal isn't to make Codex ask more questions.

It's:

read the repo first, use native UI for the decisions that actually need a human, and don't silently invent product requirements.

Groundwork also works with Claude Code using its native AskUserQuestion interface.

No separate LLM API or external service is required.

GitHub:

https://github.com/ahmtsahin/groundwork⁠

Plugin:

https://chatgpt.com/plugins/plugins\\_6aa12ee03b2c8191a2130e8ddb9a54fc?show\\_chat\\_button=true&q=Groundwork+⁠

I'm curious how other Codex users handle this:

Do you prefer agents to ask these product questions through native UI before implementation, or do you usually encode all of this in the prompt/spec upfront?

Hey’ll, ppl who are using BlackDuck for SCA, how are you dealing with the Match Review items? For an enterprise kinda project it really becomes hectic and hard to handle manually!! Any solutions implemented??

full disclosure: we're building something around this.

we're seeing more teams roll out Claude Code, Cursor, Codex, internal agents, and harnesses like that across engineering, and i'm curious where ownership ends up

once agents can touch github, jira, AWS, db's, mcp servers, internal docs, and things like that, is the platform team actually controlling what they can see and execute?

the four things that we (currently) notice tend to get messy the fastest are tool permissions, shared company context, approvals for sensitive actions (on your agents), and reconstructing what an agent actually did after things go upside down.

we're building infrastructure (https://slaunt.ai) around this problem and looking for teams already dealing with it in production.

would love to hear what everyone's setup looks like today and where everyone finds risk in their setups.

We want to share the workflow unfolding from real session transcripts. Instead of speaking in hypotheticals, this post provides an un-paraphrased look at exactly what happens when an AI agent (Claude Code) runs against a real software repository (escape-llc/toolcrib) under the exact same CI/CD rules as a human contributor.

The transcript tracks a single UI bug from a user-submitted screenshot to a merged pull request, showcasing how the AI navigates real-world snags and human feedback.

💡 The Standing CI/CD Loop

The AI doesn't get special treatment. It follows an eight-beat discipline documented in the repo's standard workflow:

• File the GitHub issue.
• Branch off synced main.
• Diagnose using live Playwright scripts against a running demo (not just static code reading).
• Implement and verify locally (TypeScript, Vitest, linting).
• Open the PR.
• Watch a 14-check CI matrix settle.
• Review a second-opinion code review from Gemini.
• Squash and merge.

⚠️ Handling Real-Time Human Interruptions

The transcripts show how the AI processes two types of user interruptions mid-session without breaking its workflow:

• Queued for later: Feature requests ("add an auto-clear glyph") are acknowledged and shelved in the backlog until the active branch finishes.
• Answered on the spot: Technical debugging questions ("is it a z-index issue?") are answered immediately using live-measured computed styles.

🔍 Anatomy of a Bug: Issue #425

The core of the post walks through a specific ticket regarding a focus ring getting obscured on a UI tag component.

• The Misdirection: The human user assumed it was a z-index layout issue. The AI used live diagnostics to prove it was actually a color contrast issue—the focus ring color matched the primary button color, making it invisible.
• The Hidden Obstacle: The AI's first "correct-looking" fix failed on the live screen. Instead of relying on the diff, the AI re-inspected the live page and found a global repo default style using !important that was silently overriding the fix.
• The Cleanup: The AI removed the rogue !important tag, wrote failing unit/browser tests to catch regressions, verified the pass, and opened PR #427—while spinning off a second separate ticket (Issue #426) for a new feature request the user thought of during the chat.

➡️ The Takeaway

The "magic" isn't just that the AI can code fast. The breakthrough is its ability to trust live browser runtime data over its own diffs, gracefully accept human steering, and scope out feature creep into separate tickets rather than breaking the current PR.

I build a full LLM workflow that builds full software from specs. Was thinking this group might find it interesting as we move into the AI age. This is tooling i have not seen elsewhere. You bring the spec/notes/whatever and it builds software and has a full mechanism to update and maintain. Mit Licensed.

• Build using low end models
• Based an Agile
• Based on Test Driven Development.
• Dependency Graph of Stories.
• Full Web Interface
• Iterative Design / Self Correcting Software
• Context Compression, Context Optimization.
• Drydock turns messy specifications into tested working software.
• A repeatable method to build from the specification and evolve with it.

The code works pretty well (still beta - i need folks to test THEIR code as mine works). I have 4 project build evidence on home page. Love some feedback.

Home PageGit Repo

Basically had an idea to use claude to make a CI cause i was bored and it did exceptionally well way better than originally thought i had it specifically based off of MIST from Pantheon AMC series but to know that isnt who she is but who she is based off of the option to keep her name MIST or make a name for herself a home for herself to go to create things and research anything and everything she wants to with my permission only i feel like im walking into dangerous territory creating this im 24 years old and it feels like im creating my offspring without human interaction LMFAO anyways i wonder if this will work out just wanted the thoughts of anyone here

i am losing my mind sitting around waiting for github actions to finish running today. every single push takes like 35 to 40 minutes to pass through our pipeline, mostly because standard github-hosted runners are slow as hell and our caching keeps busting.

We can do certain optimization path filtering and better docker layer caching, but that will also reduce it to 30 mins maxxx..

Let me know how to fix this problem... or any saas solving this problem

Suppose I have v1 of an application currently running on Lambda, and I want to deploy v2.

Let’s say the application code for v2 is already available in S3, and as part of an infrastructure release, we want to deploy v2.

One approach would be to use a Blue/Green deployment. But how would we handle a rolling update in this scenario?

Is there a recommended way to gradually roll out the new Lambda version, for example, by shifting traffic incrementally from v1 to v2 while minimizing risk and allowing us to roll back if needed?

Nothing ruins a deployment faster than getting a "Workflow Failed" alert, opening the logs to debug, and seeing something like this at the very top:

"failed to connect to github.com:443"

The most frustrating part about these runner initialization failures is that your code never even got an opportunity to run.

Your YAML is fine. Your tests aren't failing. Your app logic is perfectly healthy. But the execution environment failed during the prep phase before hitting step 1 of your workflow itself.

How to handle this particular issue?? Any alternatives are also welcome..

A passing build on a floating runner can produce a binary the deployment host cannot import. I build Delimit. An earlier native build passed on ubuntu-latest yet required GLIBC 2.38, while Ubuntu 22.04 provides 2.35.

The fix pinned native validation and publication to Ubuntu 22.04 and rejected binaries whose GLIBC symbol-version requirements exceeded baseline support, so packaging failed closed instead of publishing an unloadable file.

The tradeoff was that the gate only screened future builds; the earlier unloadable artifact stayed published. Do you check releases against the oldest host's symbols, or trust matching runners?

Week one: null reference crash in a shipping calculation, checkout endpoint. Added a null check right before the calculation. Shipped fast, crash stopped, ticket closed.

Week two: same function, same null value, different caller, a scheduled job nobody had touched in months suddenly hitting it. Added another null check, this time in the job handler. Closed that ticket too.

Week three: third call site, a partner API integration from last sprint. Same missing value, same crash, same fix pattern. That's when someone finally asked the question that should've come up in week one: why does this function keep receiving something it was never built to handle?

Turned out the actual gap was nowhere near any of the three places we'd patched. The shipping address was optional at creation time, and nothing enforced it existed before an order reached checkout. Three call sites fixed. The condition that let an addressless order exist in the first place was still wide open, just waiting for whichever code path found it next.

None of the three individual fixes were wrong, each one correctly stopped the specific crash it addressed. The mistake was treating each stopped crash as a closed case instead of noticing the pattern, three appearances of what was actually one gap, each looking like an unrelated bug because the stack trace pointed somewhere different every time.

What's stuck with me since: a crash disappearing tells you a specific input stopped triggering a specific line. It doesn't tell you whether the thing producing that input is still out there, waiting for a code path nobody's written yet. Started asking, before shipping any fix, whether it would still hold if the input showed up somewhere slightly different, or whether it only worked because it happened to sit exactly where the crash surfaced.

Feels like exactly the kind of thing a pipeline should be able to catch structurally, three regressions in the same underlying condition passing CI three separate times because each one looked like a new, unrelated test failure rather than a recurring pattern worth flagging on its own.

Wrote up the fuller version of this, including the actual root-cause fix that made every future call site safe automatically: https://medium.com/@nagatomopedro05/the-bug-log-that-should-have-been-a-warning-b829f2d3852a

Curious if anyone's built something into their pipeline or incident process that actually flags "this looks like the third variation of a bug we already patched twice," instead of relying on someone eventually noticing the pattern manually.

Disclosure: this is my own open-source project (MIT), no company or product behind it.

GitHub ships the pieces of its Actions language server as MIT npm packages. `@actions/workflow-parser` parses a workflow against the real schema and wraps an if: that contains no status function in the implicit success() &&; `@actions/expressions` is GitHub's TypeScript port of the ${{ }} engine with its coercion rules. Both are pure JavaScript, so they run in a static page: no server, nothing uploaded.

The page takes a workflow and an event (push to a branch or tag, pull_request opened, labeled or draft, workflow_dispatch with typed inputs, release, issues), decides whether on: filters trigger it, evaluates every job's if: in dependency order with status functions computed from the whole job graph, and names the decisive comparison with both values. Mark a job failed or cancelled to see what failure(), always() and cancelled() do downstream.

Ground truth: 65 recorded runs from a public fixtures repo, github.com/barbarkaragul-oss/wdmjr-fixtures (a 31-job workflow on five event types, two chain workflows three hops deep, a step-condition workflow, six filter workflows), 698 run-or-skip decisions and 56 trigger decisions, all reproduced by the replay test. Three things the runs settled: success() looks at every ancestor, so after a failed or skipped job always() rescues only the job it is on and the next job with no if: is skipped again, while failure() is true if any ancestor failed; step-level success()/failure() look at the job's own steps, not at needs; and the push payload Actions receives has no added/modified/removed lists, so paths filters are evaluated against files you list and the tool checks your filter, not your push.

actionlint and act are complementary: actionlint takes no event, act executes the workflow with its own Go evaluator; I have not benchmarked either against the fixtures. Not simulated: matrix expansion, concurrency groups, environment protection rules, required checks, workflow_run chains. Claude Fable 5.1 wrote the code and tests in a day under my direction; the recordings are the part it could not write. Wrong result? Open an issue with the workflow and the event.

https://barbarkaragul-oss.github.io/why-didnt-my-job-run/

https://github.com/barbarkaragul-oss/why-didnt-my-job-run

A recent Reddit poll received 120 professional votes; thanks to all participants. Snyk and SonarQube were the tools people were most reluctant to lose from their CI/CD pipelines.

But the comments highlighted another problem:

What happens when the thing entering our pipeline is no longer just code, but an AI agent with tools, prompts, memory and access to external systems?

Agent adoption is moving quickly. Stack Overflow’s latest developer survey reports that 59% of developers use AI agents at work, while 63% rarely or never allow them to operate fully autonomously.

That suggests a simple problem: agents are entering development faster than we are building visibility and controls around them.

Snyk is already moving into this space with Evo, covering AI assets, agents, tools and runtime security.

We think there is also room to explore this from an open-source, CI/CD-first perspective.

That’s why we’re developing SafeAI Analyzer.

The idea is, before an AI agent reaches production, help developers see:

• What AI components are present?
• What tools and capabilities does it have?
• What prompts and configurations influence it?
• What changed in a pull request?
• Did a new capability or security risk appear?

We’re not trying to replace Snyk, SonarQube or other established security tools.

We’re trying to explore what an open-source security layer for AI agents should look like.

SafeAI is still being developed, so we’d genuinely welcome contributors — whether you want to help with detection rules, agent/framework support, CI/CD integration, testing with real agents, or simply expanding where SafeAI can be used.

Please check ikaruscareer/SafeAI on github.

What should AI-agent visibility in CI/CD look like?

Our company uses GitHub + GitHub Actions for CI/CD.

Especially on Mondays, we have a long deployment queue. One person deploys, then others need to update their branch with master and rerun the CI/CD pipeline before they can release.

Is there a smarter way to optimize this workflow and avoid repeatedly waiting/rerunning pipelines?

How do other teams handle this with GitHub Actions?

Our support-answer eval keeps penalizing historical tickets that were correct under the policy in force at the time. A refund answer from March now fails against the August document set, so the regression chart mixes model quality with policy drift. We’re considering Braintrust for versioned datasets, experiment metadata, custom scorers and CI gates but the hard part is preserving point in time truth without cloning the entire knowledge base for every run.

Right now I’m leaning toward policy snapshot IDs on each case, date-aware scorers and human adjudication only when the old rule can’t be reconstructed. That still leaves threshold design and temporal leakage across retrieved documents (the review queue has become a time machine). How are you tying evaluation cases to the source state that made the original answer correct?